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with the Inmos Transputer from Computer System Architects 


APPLICATIONS 


• High-Performance • Cost Effective 

For computationally intensive applications such as simulation, 
signal processing and graphics rendering. For image processing 
and pattern recognition. For distributed databases. For real-time 
applications like transaction processing, data acquisition and robo¬ 
tics. Using from 1 to 64 (or more) processors. Incrementally 
expandable and field upgradable. 

• Acceleration for PC’s and Workstations 

For applications requiring a large, flat, memory address space. For applications which may benefit from incrementally scalable 
performance by simply adding processors. Put from 1 to 16 processors (with up to 32MB) inside the PC or use just 1 slot 
to escape to an external chassis. One transputer is up to 3 times faster than a Deskpro 386/25 with 80387! 


HARDWARE 



Compute Nodes 

Processors: Inmos T425 or T800 32-bit transputers. Up to 
12.5 MIPS and 1.25 64-bit MFLOPS (with no vector pipelining 
required). Two on-chip timers facilitate real-time applications. 

Hardware scheduler supports multiple processes on each processor. 

Links: Each processor has 4 bidirectional serial communication 
links, providing data transfer between nodes at up to 9MB/sec 
(overlapped with computation). Links are differentially buffered 
and user-configurable, allowing multi-cabinet systems. Memory: Each node has 4KB of 50 nsec SRAM and up to 8MB of 
local DRAM. Size: 1 to 4 nodes per board, with up to 20 boards per cabinet. Boards also fit in PC’s and AT’s. 

Cost: Compute nodes range in price from $900 (a 20 MHz T425 with 256KB) to $5,995 (a 25MHz T800 with 8MB). 



CSA PART 6A: Four T800 transputers with 1 MByte RAM per processor 
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Interfaces for PC and AT hosts. Also for Apollo and SUN-386i workstations which use the AT bus. For hosts and peripherals 
using the VME bus, including the Apollo-10000 and SUN-3 and -4. A SCSI interface is even available, allowing direct 
connection of disks and other SCSI peripherals. Also for hosts with a SCSI port, like the Macintosh. 

Accessories include a transputer-based color graphics controller, a 32 x 32 link switch (allowing programmable reconfig 
uration of link connections), and a proto-board (with 16-bit T222 processor and SRAM/EPROM) facilitating custom data 
acquisition and real-time control. 
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• ANSI Standard C • FORTRAN 77 • Modula 2 • Occam 2 • Pascal 


Compilers come with transputer network loaders, concurrency and 
message passing libraries, and host server programs for DOS or 
UNIX. Prices start at $400 (a complete C development system). 

• Operating Environments and Libraries 

Express from ParaSoft and Helios from Perihelion. Debuggers. 
Math libraries fromTopexpress. Graphics libraries. And more. 
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TEACHING AN OBJECT-ORIENTED LANGUAGE 


VehicleObj = OBJECT 

course: [ 0 .. 359 ]; 
speed: INTEGER; 
position: LOCType; 

METHOD ProceedTo(IN Dest: LocType); 

METHOD Stop; 

END OBJECT; 

AircraftObj = OBJECT(VehicleObj,GraphicsObj); 
altitude: INTEGER; 

OVERRIDE 

ASK METHOD Stop; 

END OBJECT; 


MODSIMII - the object-oriented language for teachers 


Now for universities 

MODSIM II - an Object-Oriented language for 
Programming, Simulation, and Graphics 


M ODSIM II™ simplifies your 
teaching of object-oriented 
programming, simulation, and graphics. 

MODSIM II objects can be defined 
through multiple inheritance, and stu¬ 
dents can override and redefine 
methods and add fields. All objects are 
dynamically created virtual objects. 
They invoke method code at runtime, 
and communicate through message 
passing. 

MODSIM II has the facilities your 
students need to develop and maintain 
reusable code. Students’ programs can 
be divided into separately compiled 
modules, and common constructs can 
be imported from libraries. 

Easy-to-understand graphics 

Designing a graphical interface is 
simplified through the use of the 
SIMGRAPHICSII Graphics Editor. 

Students see exactly what their 
graphics will look like - no struggling 
with graphics primitives. Their input 
forms can contain menu bars, buttons, 
and other powerful input tools. 

The graphs, icons, and input forms 
described using the Graphics Editor are 
connected directly to variables and con¬ 
trol code in the student’s program. 


Low cost to 
universities 

CACI recognizes the benefits of 
having this state-of-the-art language 
used by universities. 

For that reason we make the 
MODSIM II object-oriented program¬ 
ming teaching package available to 
universities for only a low distribution 
fee. 

The package includes training, sup¬ 
port, complete documentation, and 
sample programs - everything you 
need to conveniently teach object- 
oriented programming. 

We will also provide paper copies of 
a complete set of course transparencies. 

Act now - limited offer 

This offer is limited to 150 univer¬ 
sities. We want to work closely with 
the academic community. Don’t be dis¬ 
appointed - call today. 

For immediate information 

Call Eric Chapman at (619) 457- 
9681, FAX (619) 457-1184. In Europe, 
call Karen Shannon on (01) 528-7980, 
FAX (01) 528-7988. 


Rush information on the object- 
oriented teaching package for 
universities only. 


Also send information on: 

□ NETWORK II.5® for teaching network 
analysis - no programming. 

□ COMNET II.5® for teaching communica¬ 
tion network analysis - no programming. 

□ SIMFACTORY II.5® for teaching factory 
planning — no programming. 

□ SIMSCRIPT II.5® for teaching simulation 
with graphics. 
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Kenneth R. Anderson 


T his month I am pleased to have the 
society’s treasurer, Chuck Silio, 
report on the financial results of 
fiscal year 1988. It represents a stable, 
balanced budget and growth in reserves, 
which are essential to the society’s suc¬ 
cess in the 1990s and beyond. Congratu¬ 
lations to both staff and volunteers for an¬ 
other excellent year. 

Kenneth R. Anderson 
President 


1988 financial 
results 


For the third consecutive year the Com¬ 
puter Society has demonstrated financial 
health and stability. Under the guidance 
of 1988 President Ed Parrish and 1988 
Treasurer Barry Johnson, the society 
posted a $126,800 surplus, $100,600 of 
which represents surpluses in funds des¬ 
ignated exclusively for use by technical 
committees and $26,200 of which repre¬ 
sents surpluses from all other society ac¬ 
tivity. Steady financial growth has al¬ 
lowed the Computer Society to enhance 
and increase its services to members in 
1988, including the approval of a new 
publication and increased pages in exist¬ 
ing publications. Furthermore, the soci¬ 
ety improved its capacity to respond to 
members’ needs by establishing and 
staffing an office in Tokyo modeled after 
the society’s successful Brussels office. 
Increased investment in membership 
promotion paid dividends in 1988 as 
Computer Society membership grew 12 
percent to over 100,000 members. I am 
pleased to report that the Computer Soci¬ 
ety is in sound financial condition and 
better equipped than ever to serve its 
membership. 

Computer Society auditors, Coopers & 
Lybrand, have completed the 1988 audit 
and believe that the financial statements 
presented here fairly represent the finan¬ 
cial position of the IEEE Computer Soci¬ 
ety as of December 31,1988 and 1987. An 
analysis of these statements reveals an in¬ 
teresting profile of Society activities: 


• In 1988, the large majority of total 
expenditures were program activi¬ 
ties: 57 percent on publications and 
25 percent on conferences and other 
technical activities. Only 18 percent 
of the budget was spent on admini¬ 
stration. 

• Sources of income are diverse, and 
the society does not rely too heavily 
on membership dues, which ac¬ 
counted for only 7 percent of total in¬ 
come in 1988. 

• Increases in expenses outpaced in- 
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Report of independent accountants 



Charles B. Silio 


creases in income by 3 percent in 
1988, a trend that is being monitored 
and for which cost control and reve- 
t nue enhancement measures are being 

pursued. 

• The society’s net worth surpassed 
$3,000,000 in 1988. 

The surpluses generated during the last 
| three fiscal years are relatively small as a 

percentage of their corresponding oper¬ 
ating budgets but are very important to 
the society’s long-term strength. As tech¬ 
nologies advance and members demand 
new and different services (for example, 
electronic dissemination of publica¬ 
tions), the Computer Society must have 
the financial strength and stability to re¬ 
spond to the evolving needs. Thus, the 
society must continue to increase re¬ 
serves if it is to have the working capital 
necessary to undertake such initiatives. If 
the society can continue its trend of excel¬ 
lent financial management, it can look 
forward to the challenges of the future 
with confidence. 

Charles B. Silio 

Treasurer 


Board of Governors of the IEEE Com¬ 
puter Society: We have audited the ac¬ 
companying balance sheets of the IEEE 
Computer Society (the society) as of 
December 31, 1988 and 1987, and the re¬ 
lated statements of revenue, expenses, 
and changes in fund balance for the 
years then ended. These financial state¬ 


ments are the responsibility of the soci¬ 
ety’s management. Our responsibility is 
to express an opinion on these financial 
statements based on our audits. 

We conducted our audits in accor¬ 
dance with generally accepted auditing 
standards. Those standards require that 
we plan and perform the audit to obtain 


IEEE Computer Society 
Balance Sheets 
December 31,1988 and 1987 


Assets 

1988 

1987 

Current assets: 



Cash, including interest-bearing accounts 

$ 520,000 

$ 228,300 

Investments (Note 3) 

2,374,500 

2,737,100 

Accounts receivable, less allowance for 



doubtful accounts of $72,200 in 1988 and 



$81,300 in 1987 

1,075,600 

575,900 

Receivable from Institute of Electrical 



and Electronics Engineers, Inc. (Note 7) 

56,900 

43,000 

Conference receivables 

639,800 

710,300 

Conference advances 

126,800 

165,800 

Inventory 

487,800 

398,200 

Prepaid expenses and other assets 

839,400 

580,100 

Total current assets 

6,120,800 

5,438,700 

Fixed assets, net (Note 4) 

3,644,600 

3,658,700 

Total assets 

$9,765,400 

$9,097,400 

Liabilities and Fund Balance 



Current liabilities: 



Accounts payable and accrued expenses 

$1,594,000 

$1,162,500 

Current portion of long-term debt 

84,200 

540,200 

Demand note payable to bank 

398,500 

— 

Deferred income: 



Membership fees and subscriptions 

3,252,600 

3,065,900 

Conferences 

15,000 

19,800 

Advertising and other 

132,700 

58,400 

Total current liabilities 

5,477,000 

4,846,800 

Long-term debt, less current portion 

1,277,100 

1,366,100 

Total liabilities 

6,754,100 

6,212,900 

Fund balance: 



Undesignated 

2,819,300 

2,793,100 

Designated for technical committees (Note 8) 

192,000 

91,400 

Total fund balance 

3,011,300 

2,884,500 

Total liabilities and fund balance 

$9,765,400 

$9,097,400 
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IEEE Computer Society 

Statements of Revenue, Expenses and Changes in Fund Balance 
for the years ended December 31,1988 and 1987 



1988 

1987 

Revenue: 

Computer Society membership fees 
Periodical subscriptions and other 

$ 1,183,900 

$ 1,099,300 

publication activities 

Conventions, conferences and other 

9,236,500 

8,594,500 

technical activities 

5,083,400 

4,574,200 

Interest income 

141,300 

118,000 

Other income 

381,200 

322,600 

Total revenue 

$16,026,300 

$14,708,600 

Expenses: 

Periodical and publication activities 
Conventions, conferences and other 

$ 9,094,500 

$ 8,418,900 

technical activities 

3,953,800 

3,829,500 

Administration 

2,851,200 

1,932,000 

Total expenses 

$15,899,500 

$14,180,400 

Excess of revenue over expenses 

126,800 

528,200 

Fund balance at beginning of year 

2,884,500 

2,356,300 

Fund balance at end of year 

$ 3.011,300 

$ 2,884,500 


reasonable assurance about whether the 
financial statements are free of material 
misstatement. An audit includes exam¬ 
ining, on a test basis, evidence support¬ 
ing the amounts and disclosures in the fi¬ 
nancial statements. An audit also in¬ 
cludes assessing the accounting prin¬ 
ciples used and significant estimates 
made by management, as well as evalu¬ 
ating the overall financial statement 
presentation. We believe that our audits 
provide a reasonable basis for our opin- 

In our opinion, the financial state¬ 
ments referred to above present fairly, in 
all material respects, the financial posi¬ 
tion of the IEEE Computer Society as of 
December 31, 1988 and 1987, and the 
results of its operations for the years 
then ended, in conformity with gener¬ 
ally accepted accounting principles. 

Cooper & Lybrand 
Washington, DC 
April 14, 1989 


Notes to financial 
statements 

1. Organization and purpose 

The IEEE Computer Society (the so¬ 
ciety) is organized within the Institute of 
Electrical and Electronics Engineers, 
Inc. (IEEE), an organization exempt 
from income tax, pursuant to Internal 
Revenue Code Section 501(c) (6). 

Within the bylaws of IEEE, delegation 
of the responsibility for the society’s 
operations has been placed with the so¬ 
ciety’s Board of Governors and Execu¬ 
tive Committee. The society’s 
constitution states that “The society 
shall be scientific, literary, and educa¬ 
tional in character. The society shall 
strive to advance the theory, practice, 
and application of computer and infor¬ 
mation processing science and technol¬ 
ogy, and shall maintain a high profes¬ 
sional standing among its members. The 
society shall promote cooperation and 


exchange of technical information 
among its members and to this end shall 
hold meetings for the presentation and 
discussion of technical papers, shall 
publish technical journals, and shall, 
through its organization and other ap¬ 
propriate means, provide for the needs 
of its members.” 

2. Summary of significant accounting 
policies 

Reporting entity 

The accompanying financial state¬ 
ments include all society accounts main¬ 
tained at the society’s offices in Wash¬ 
ington, DC; Los Alamitos, California; 
Brussels, Belgium; Tokyo, Japan; and 
certain accounts maintained at IEEE 
Headquarters. The accompanying fi¬ 
nancial statements do not include the ac¬ 
counts of society chapters, which oper¬ 
ate directly under IEEE. 

Income recognition 

Income from annual membership fees 


and periodical subscriptions is recog¬ 
nized during the year to which it per¬ 
tains. The society’s share of revenue and 
expenses for conferences partially or 
entirely sponsored by the society is gen¬ 
erally recognized in the year in which 
the conference is held. 

Inventory 

Inventory consist of tutorial books 
published by the society and is stated at 
the lower of cost or market. Cost is deter¬ 
mined on an average cost basis. 

Fixed assets and depreciation 

Fixed assets are recorded at cost when 
purchased. The society provides for de¬ 
preciation of fixed assets by charges to 
revenue at rates considered adequate to 
amortize the cost of such assets over 
their estimated useful lives (5 to 10 years 
for office furniture and equipment; 30 
and 25 years for buildings) on a straight- 
line basis. 

When fixed assets are retired or other¬ 
wise disposed of, the property and accu- 
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Table 1. Fixed assets as of December 31. 



1988 

1987 

Land 

Buildings and improvements 

Warehouse equipment 

Office furniture and equipment 

$1,334,400 

1,879,500 

15,500 

1,152,400 

$1,334,400 

1,859,700 

29,500 

1,496,500 

Accumulated depreciation 

4,381,800 

(737,200) 

4,720,100 

(1,061,400) 


$3,644,600 

$3,658,700 


Table 2. Notes payable as of December 31. 



Annual 

interest 

rate 

1988 

1987 

Note payable, 

balance due on May 1, 1990 

Prime 

$1,153,500 

$1,186,600 

Note payable, balance 

due on September 25, 1992 

9.5% 

207,800 

263,100 

Note payable. 

balance paid off in May 1988 

12.0% 

-= 

456,600 

Less: Amount due within one year 


1,361,300 

84,200 

1,906,300 

540,200 


$1,277,100 

$1,366,100 


mulated depreciation accounts are re¬ 
lieved of the applicable amounts and any 
profit or loss is reflected in revenue. 

3. Investments 

Investments, which consist of unre¬ 
stricted deposits with IEEE and bear in¬ 
terest based on United States Treasury 
Bill rates, are carried at cost which ap¬ 
proximates market. 

4. Fixed assets 

Fixed assets as of December 31 are 
shown in Table 1. 

Depreciation expense was $296,900 
and $238,400 in 1988 and 1987, respec¬ 
tively. 

5. Long-term debt 

Notes payable as of December 31 
were as shown in Table 2. 

The note payable, due May 1, 1990, is 
collateralized by a first lien on all gross 


revenues of the society and a mortgage 
on the Washington, DC, property. Re¬ 
payment is in graduating amounts \ 
through the term of the note with the bal¬ 
ance payable on May 1, 1990. 

The note payable, due September 25, 
1992, is collateralized by certain equip¬ 
ment which was purchased with the pro¬ 
ceeds. Repayment is in equal monthly 
principal installments of $4,616, plus 
interest, with the balance payable on 
September 25, 1992. 

The note payable, due May 24, 1988, 
was collateralized by a deed of trust on 
one of the two buildings located in Los 
Alamitos, California. Repayment was in 
equal monthly payments of $5,200, in¬ 
cluding interest, and the balance was 
paid in full in May 1988. 

In September 1988, the society en¬ 
tered into a working capital loan agree¬ 
ment, which provides for a maximum 
borrowing of $300,000 at the bank’s 
floating prime rate. At December 31, 
1988, there were no outstanding bor¬ 
rowings under the agreement. 


Interest expense relating to all of the 
above notes amounted to $150,000 and 
$177,400 in 1988 and 1987, respectively. 

Annual maturities of long-term debt 
outstanding as of December 31, 1988 are 
as follows: 1989 — $84,200; 1990 — 
$1,180,100; 1991 — $55,400; and 1992 
— $41,600. 

6. Pension plan 

The society is a member of a defined- 
benefit pension plan sponsored by 
IEEE. The IEEE plan covers substan¬ 
tially all IEEE employees, including 
those of the society. It is the policy of 
IEEE to fund pension costs accrued. 

Effective January 1, 1987, IEEE 
adopted Statement of Financial Ac¬ 
counting Standards (SFAS) No. 87, 
“Employees Accounting for Pensions.” 
SFAS 87 requires that certain disclo¬ 
sures be made of the actuarial present 
value of benefit obligation and accrued 
pension costs. Such disclosures are not 
presented for the society because the 
structure of the IEEE plan does not read¬ 
ily permit the plan’s assets and benefit 
obligation data to be determined for each 
individual society. Based upon actuarial 
valuations of the IEEE plan, assuming a 
discount rate and an expected long-term 
rate of return on assets of 8.5 percent and 
an increase in the level of compensation 
of 6.5 percent, the IEEE plan assets ex¬ 
ceeded the projected benefit obligation 
at December 31, 1988 and 1987. 

The society was allocated no pension 
expense in 1988, but was allocated a net 
pension credit of approximately 
$17,000 in 1987 (due to the adoption of 
SAFS 87) based upon its respective 
share of total payroll and benefit costs. 

7. Related-party transactions 

Certain general and administrative 
expenses incurred by IEEE Headquar¬ 
ters and charged to the society amounted 
to $898,600 in 1988 and $766,400 in 
1987. Other transactions undertaken in 
the normal course of business between 
the society and IEEE have been reflected 
in the society's financial statements. 

8. Designated fund balance 

The Board of Governors has desig¬ 
nated a portion of surplus funds received 
from recurring conferences for use by 
technical committees in accordance 
with the society’s policy on meeting sur¬ 
plus accounts. The designated amounts 
are calculated based upon a formula con¬ 
tained in the policy, but in no case can 
they exceed $30,000 ($15,000 for 1987) 
per technical committee conference. 
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LETTERS 


“Software engineering” 

To the Editor: 

Admittedly, I’m not among the most 
qualified of your readers to comment on 
Robert Baber’s statements regarding the 
proper use of the title software engineer 
(Open Channel, May 1989, p. 81), but it’s 
a question I’ve had to face with serious 
social, professional, and economic con¬ 
sequences. 

Several years ago, when I entered the 
computer field on a full-time basis, I 
joined a small software company. I had 
been attracted to the company because it 
approached design and development dif¬ 
ferently than I had experienced else¬ 
where. We were faced with developing 
circuits and software to solve unique and 
complex data communications problems 
for the commercial world, a field in which 
“electrospiritualism” and brute-force 
methods were all too common. This com¬ 
pany’s, on the other hand, was open, prag¬ 
matic, and entirely rational. 

I had earned a living as a “program¬ 
mer” and “consultant” previously, but 
came from a nonengineering academic 
discipline (PhD, music theory). Because 
of my lack of a formal degree in computer 
science, I was reluctant to adopt the title 
“software engineer” as others in the 
company had. But, I was to discover, they 
had their reasons. This company was in a 
largely industrial, blue-collar city where 
the title “engineer” granted definite pro¬ 
fessional advantages and respectability. 
Also, with the overall dearth of good 
minds for this kind of work, several of my 
coworkers had crossed over from other 
engineering disciplines. 

But, that wasn’t enough to convince 
me. Soon, however, it became obvious to 
me that there was a strong similarity, if 
not identical mission, in what we were 
doing to that of the mechanical, electri¬ 
cal, and civil engineers I interacted with 
professionally. Our approaches, meth¬ 
ods, and theoretical base were indistin¬ 
guishable. The gap between us was that 
suggested in Baber’s definition of engi¬ 
neering as, “[t]he application of scien¬ 
tific knowledge and principles to the task 
of designing and constructing a device, 
machine or system of economic value ...” 
For the software engineer, where is that 
body of scientific knowledge and prin¬ 
ciples? It’s our science that is lacking, not 
our engineering. We’re still struggling to 
define and formalize what we do so that 
we can measure and communicate in pre¬ 
cise ways about the problems we solve. 
Yet, my personal experience leads me to 


vs. software engineering 

believe that extraordinary engineering 
feats are being performed every day by 
software engineers, based on this rela¬ 
tively primitive science. 

So, is software engineering legitimate, 
and are there bonafide software engineers 
among us? My answer, “Absolutely.” I 
would ask the engineering establishment 
to be sympathetic and patient for a little 
while. In general, software engineers un¬ 
derstand the burden of being accepted as 
true engineers, and we’re doing our best 
to feed back to computer scientists the 
questions critical to advancing our field. 
While waiting for those answers, we’re 
perfecting our ability to apply what com¬ 
puter science has yielded and developing 
highly reliable software systems as 
needed for the space program, military, 
transportation, business, and medicine. 

In time, we’re confident of meeting every 
possible criteria for defining “engineer” 
that may be raised. 

Lawrence T. Woodruff 

Westport, Connecticut 

Author’s reply: 

I thank Lawrence Woodruff for taking 
the time to write his comments, with 
which I largely agree. However, in my 
view, computing science has already 
given us a theoretical foundation for a 
truly engineering approach to designing 
software. I refer especially to the work of 
Dijkstra, Floyd, Hoare, and Mills. We 
software developers are only beginning 
to absorb this material and to apply it in 
our regular work. This body of scientific 
knowledge and principles — and espe¬ 
cially its application in software develop¬ 
ment practice — is the subject of my sec¬ 
ond book, The Spine of Software: Design¬ 
ing Provably Correct Software — Theory 
and Practice (Wiley, 1987). 

To be sure, computing scientists have 
not finished their job of providing us with 
the fundamental knowledge we need. But 
neither are physicists finished providing 
electrical, mechanical, and other engi¬ 
neers with new knowledge for their work. 

I, too, am confident that we will, in 
time, meet all reasonable criteria for en¬ 
gineering. But we still have a way to go. 
While the engineering establishment is 
being sympathetic and patient with us, 
they and the rest of society should keep 
pressure on us, lest we be complacent, as 
human beings seem often wont to be. 

Robert L. Baber 

Homburg, FRG 
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Do you practice Yourdon/DeMarco Structured Analysis? 
Do you need to produce high quality DFD's? 

Do you need a tool that fits your budget? 

Then MacBubbleS ™ was made foryou! 


MacBubbles supports the process of structured analysis with: 

Facilities for creating, modifying, leveling and expanding DFD's 
A Data Dictionary that maintains and lists full where-used information 
Automated balancing checks for DFD's and minispecs 

MacBubbles improves productivity: MacBubbles is economical: 

Easy to learn Single copy price $779.99 

Easy to use Multi-copy discount available 

Responsive Demo disk $25.00 
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A Macintosh Plus or SE 
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A LaserWriter for high quality output 
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Philips Laboratories 

Briarcliff Manor, New York 

Intelligent Systems Research 

■ Medical Imaging 

■ Office Automation 

■ Knowledge-Based Systems 


The Intellisent Systems Department 
of PHILIPS LABORATORIES, a divi¬ 
sion of North American Philips Cor¬ 
poration, is seekins experienced 
candidates to participate in long¬ 
term research leading to applica¬ 
tions in Medical Image Processing 
and the Automated Office 
Environment. 

MEDICAL IMAGING 
RESEARCHER 

The ideal candidate should have a 
Ph.D. or equivalent in an ap¬ 
propriate subject and substantial 
prior experience in low-level image 
processing. Expertise is required in 
texture analysis, image morphol¬ 
ogy, feature detection, and 
statistical pattern classification. Ex¬ 
perience with medical imaging 
(particularly image processing of 
conventional radiographs) is highly 
desirable, but not essential. The 
Medical Imaging group conducts 
research in image enhancement, 
segmentation and contour extrac¬ 
tion, multi-sensor fusion, and quan¬ 
titative analysis. 


An equal opportunity employer M/F/H. 


OFFICE AUTOMATION 

You should have a Ph.D. or 
equivalent in an appropriate sub¬ 
ject, and substantial involvement in 
prior research in computer- 
supported cooperative work. We 
are interested in multi- and hyper¬ 
media systems, intelligent agents, 
groupware, collaborative technol¬ 
ogies, and distributed processing 
systems. 

KNOWLEDGE-BASED 

SYSTEMS 

This position involves research in 
modeling the dynamics of an 
organization, and building 
knowledge-based applications 
that make use of the model, such as 
expert assistants or independent 
agents. We are looking for people 
with a Ph.D. or equivalent in an ap¬ 
propriate subject, and prior ex¬ 
perience in reconfigurable 
knowledge bases, modeling uncer¬ 
tainty, or machine learning tech¬ 
niques for knowledge acquisition. 


PHILIPS LABORATORIES is located 
on the east side of the Hudson 
River, approximately 1 hour north 
of New York City. Surrounding com¬ 
munities provide an excellent 
lifestyle with recognized school 
systems. 

We offer a competitive salary and 
comprehensive benefits package. 
To expedite the handling of your 
response, please indicate the area 
of interest on your envelope and 
send your resume detailing your 
qualifications, to: Human Re¬ 
sources Representatative, 
PHILIPS LABORATORIES, 345 
Scarborough Road, Briarcliff 
Manor, NY 10510. 


North American 
Philips Corporation 












The Xerox Star: 

A Retrospective 

Jeff Johnson and Teresa L. Roberts, US West Advanced Technologies 
William Verplank, IDTwo 
David C. Smith, Cognition, Inc. 

Charles H. Irby and Marian Beard, Metaphor Computer Systems 
Kevin Mackey, Xerox 


X erox introduced the 8010 “Star” 
Information System in April of 
1981. That introduction was an 
important event in the history of personal 
computing because it changed notions of 
how interactive systems should be de¬ 
signed. Several of Star’s designers, some 
of us responsible for the original design 
and others for recent improvements, de¬ 
scribe in this article where Star came from, 
what is distinctive about it, and how the 
original design has changed. In doing so, 
we hope to correct some misconceptions 
about Star that we have seen in the trade 
press and to relate some of what we have 
learned from designing it. 

For brevity, we use the name “Star” 
here to refer to both Star and its successor, 
ViewPoint. “ViewPoint” refers exclu¬ 
sively to the current product. 

What Star is 

Star was designed as an office automa¬ 
tion system. The idea was that profession¬ 
als in a business or organization would 
have workstations on their desks and 
would use them to produce, retrieve, dis¬ 
tribute, and organize documentation, 
presentations, memos, and reports. All of 
the workstations in an organization would 
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The Xerox Star has 
significantly affected 
the computer industry. 
In this retrospective, 
several of Star’s 
designers describe its 
important features, 
antecedents, design 
and development, 
evolution, and some 
lessons learned. 


be connected via Ethernet and would share 
access to file servers, printers, etc. 

Star’s designers assumed that the target 
users were interested in getting their work 
done and not at all interested in computers. 
Therefore, an important design goal was to 
make the “computer” as invisible to users 
as possible. The applications included in 
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the system were those that office profes¬ 
sionals would supposedly need: docu¬ 
ments, business graphics, tables, personal 
databases, and electronic mail. The set 
was fixed, always loaded, and automati¬ 
cally associated with data files, eliminat¬ 
ing the need to obtain, install, and start the 
right application for a given task or data 
file. Users could focus on their work, 
oblivious to concepts like software, oper¬ 
ating systems, applications, and programs. 

Another important assumption was that 
Star’s users would be casual, occasional 
users rather than people who spent most of 
their time at the machine. This assumption 
led to the goal of having Star be easy to 
learn and remember. 

When Star was introduced in 1981, its 
bitmapped screen, windows, mouse- 
driven interface, and icons were readily 
apparent features that clearly distin¬ 
guished it from other computers. Soon, 
however, others adopted these features. 
Today, windows, mice, and icons are more 
common. However, Star’s clean, consis¬ 
tent user interface has much more to do 
with its details than with its gross features. 
We list here the features that we think make 
Star what it is, categorized according to 
their level in the system architecture: ma¬ 
chine and network, window and file man¬ 
ager, user interface, and document editor. 
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Machine and network level. Impor¬ 
tant aspects of Star can be found in the low¬ 
est levels of its architecture: the machine 
and the network of which it is a part. 

Distributed, personal computing. 
Though currently available in a stand¬ 
alone configuration. Star was designed 
primarily to operate in a distributed 
computing environment. This approach 
combines the advantages and avoids the 
disadvantages of the two other primary ap¬ 
proaches to interactive computing: time- 
shared systems and stand-alone personal 
computers. 

Time-shared systems, dominant through 
the sixties and seventies, allow sharing of 
expensive resources like printers and 
large data stores among many users and 
help assure the consistency of data that 
many must use. Timesharing has the disad¬ 
vantages that all users depend upon the 
continued functioning of the central com¬ 
puter and that system response degrades as 
the number of users increases. 

Personal computers, which have re¬ 
placed timesharing as the primary mode of 
interactive computing, have the advan¬ 
tage, as one Xerox researcher put it, “of 
not being faster at night.” Also, a collec¬ 
tion of personal computers is more reliable 
than are terminals connected to a central¬ 
ized computer: system problems are less 
apt to cause a total stoppage of work. The 
disadvantages of PCs, of course, are the 
converse of the advantages of timeshar¬ 
ing. Companies that use stand-alone PCs 
usually see a proliferation of printers, in¬ 
consistent databases, and nonexchange¬ 
able data. 

The solution, pioneered by researchers 
at Xerox (see “History of Star develop¬ 
ment” below) and embodied in Star, is to 
connect personal workstations with a lo¬ 
cal area network and to attach shared re¬ 
sources (file servers, database servers, 
printers) to that same network. 

Mouse. An interactive computer system 
must provide a way for users to indicate 
which operations they want and what data 
they want those operations to be per¬ 
formed on. Users of early interactive sys¬ 
tems specified operations and operands 
via commands and data descriptors (such 
as text line numbers). As video display ter¬ 
minals became common, it became clear 
that it was often better for users to specify 
operands — and sometimes operations — 
by pointing to them on the screen. It also 
became clear that graphic applications 
should not be controlled solely with a key¬ 


board. In the sixties and seventies, people 
invented many different pointing devices: 
the light pen, the trackball, the joystick, 
cursor keys, the digitizing tablet, the touch 
screen, and the mouse. 

Like other pointing devices, the mouse 
allows easy selection of objects and trig¬ 
gering of sensitive areas on the screen. The 
mouse differs from touch screens, light 
pens, and digitizing pads in that it is a rela¬ 
tive pointing device: the movement of the 
pointer on the screen depends upon mouse 
movement rather than position. Unlike 
light pens, joysticks, and digitizing pads, 
the mouse (and the corresponding pointer 
on the screen) stays put when the user lets 
go of it. 

To achieve satisfactory mouse-track¬ 
ing performance. Star handles the mouse 
at a very low level. In some workstations, 
the window system handles mouse track¬ 
ing, with the result that the mouse pointer 
often jerks around the screen and may even 
freeze for seconds at a time, depending 
upon what else the system is doing. The 
mouse is a hand-eye coordination device, 
so if the pointer lags, users just keep mov¬ 
ing the mouse. When the system catches 
up, the mouse moves beyond the user’s 
target. We at Xerox considered this unac¬ 
ceptable. 

Star uses a two-button mouse, in con¬ 
trast with the one-button mouse used by 
Apple and the three-button mouse used by 
most other vendors. Though predecessors 
of Star developed at Xerox Palo Alto Re¬ 
search Center (see “History of Star devel¬ 
opment” below) used a three-button 
mouse, Star’s designers wanted to reduce 
the number of buttons to alleviate confu¬ 
sion over which button did what. Why stop 
at two buttons instead of reducing the 
number to one, as Apple did? Because 
studies of users editing text and other ma¬ 
terial showed that a one-button mouse 
eliminated button-confusion errors only 
at the cost of increasing selection errors to 
unacceptable levels. 

Bitmapped display. Until recently, 
most video display terminals were charac¬ 
ter-mapped. Such displays enable vast 
savings in display memory, which, when 
memory was expensive, made terminals 
more affordable. 

In the seventies, researchers at Xerox 
PARC decided that memory would get 
cheaper eventually and that a bitmapped 
screen was worth the cost anyway. They 
thus developed the Alto, which had a 
screen 8.5 inches wide and 10.5 inches tall 
and an instruction set specially designed 


for manipulating display memory. 

Like the Alto, Star’s display has a reso¬ 
lution of 72 pixels per inch. The number 72 
was chosen for two reasons. First, there are 
72 printer’s points per inch, so 72 pixels 
per inch allows for a smooth interface with 
the world of typesetting and typography. 
Second, 72 pixels per inch is a high enough 
resolution for on-screen legibility of a 
wide range of graphics and character sizes 
(down to about eight points — see Figure 
1), but not so high as to cause an onerous 
memory burden, which a screen that 
matched the 300 dots-per-inch printer 
resolution would have. Unlike many PC 
graphic displays, the pixel size and density 
are the same horizontally and vertically, 
which simplifies the display software and 
improves image quality. 

Window and file manager level. Just 
above Star’s operating system (not dis¬ 
cussed here) are facilities upon which its 
distinctive user interface rests. 

Windows. Systems now commonly al¬ 
low several programs to display informa¬ 
tion simultaneously in separate areas of 
the screen, rather than each taking up the 
entire display. Star was the first commer¬ 
cial system to provide this capability. 

Some windowing systems allow win¬ 
dows to overlap each other. Other systems 
don’t; the system adjusts the size and posi¬ 
tion of windows as they are opened and 
closed. Star’s windowing system could 
overlap windows and often did (for ex¬ 
ample, property sheets appeared in win¬ 
dows overlapping application windows). 
However, early testing revealed that users 
spent a lot of time adjusting windows, usu¬ 
ally so they did not overlap. Because of 
this, and because Star’s 17-inch screen 
reduced the need for overlapping win¬ 
dows, the designers decided to constrain 
application windows to not overlap. How¬ 
ever, some situations benefit from over¬ 
lapping application windows. This, added 
to a subsequent reduction in the standard 
screen size to 15 inches (with a 19-inch 
screen optional), resulted in optional con¬ 
straints for ViewPoint, Star’s successor, 
with the default setting allowing applica¬ 
tion windows to overlap one another. 

Integrated applications. “Integrated” 
has become a buzzword used to describe 
many things. Here, it means that text, 
graphics, tables, and mathematical for¬ 
mulas are all edited inside documents. In 
many other systems, different types of 
content are edited in separate application 
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Figure 1. Viewpoint screen image. Star’s bitmapped display, once unique in the marketplace, is now much more common. 
Such a display permits WYSIWYG editing, display of proportionally spaced fonts, integrated text and graphics, and 
graphical user interfaces. 


windows and then cut and pasted together. 
For example, a MacDraw drawing put into 
a Microsoft Word or Aldus Pagemaker 
document can no longer be edited; rather, 
the original must be re-edited with 
MacDraw and then substituted for the old 
drawing in the document. 

Not even Star is fully integrated in the 
sense used here. For example, though the 
original structured graphics editor, the 
new one (see “History of Star develop¬ 
ment” below), and the table and formula 
editors all operate inside text files, spread¬ 
sheets and freehand drawings are cur¬ 
rently edited in separate application win¬ 
dows and transferred into documents, 
where they are no longer fully editable. 

User-interface level. Star’s user inter¬ 
face is its most outstanding feature. In this 
section we discuss important aspects of 
the interface in detail. 


Desktop metaphor. Star, unlike all con¬ 
ventional systems and many window- and 
mouse-based ones, uses an analogy with 
real offices to make the system easy to 
learn. This analogy is called “the Desktop 
metaphor.” To quote from an early article 
about Star: 

Every user’s initial view of Star is the Desk¬ 
top, which resembles the top of an office desk, 
together with surrounding furniture and 
equipment. It represents a working environ¬ 
ment, where current projects and accessible 
resources reside. On the screen are displayed 
pictures of familiar office objects, such as 
documents, folders, file drawers, in-baskets, 
and out-baskets. These objects are displayed 
as small pictures, or icons. 

The Desktop is the principal Star technique 
for realizing the physical office metaphor. 
The icons on it are visible, concrete embodi¬ 
ments of the corresponding physical objects. 
Star users are encouraged to think of the ob¬ 
jects on the Desktop in physical terms. You 
can move the icons around to arrange your 


Desktop as you wish. (Messy Desktops are 
certainly possible, just as in real life.) You can 
leave documents on your Desktop indefi¬ 
nitely, just as on a real desk, or you can file 
them away. 1 

Having windows and a mouse does not 
make a system an embodiment of the Desk¬ 
top metaphor. In a Desktop metaphor sys¬ 
tem, users deal mainly with data files, 
oblivious to the existence of programs. 
They do not “invoke a text editor,” they 
“open a document.” The system knows 
the type of each file and notifies the rele¬ 
vant application program when one is 
opened. 

Most systems, including windowed 
ones, use a Tools metaphor, in which users 
deal mainly with applications as tools. 
Users start one or more application pro¬ 
grams (such as a word processor or spread¬ 
sheet), then specify one or more data files 
to edit with each. Such systems do not ex- 
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plicitly associate applications with data 
files. Users bear the burden of doing that— 
and of remembering not to try to edit a 
spreadsheet file with the text editor or vice 
versa. User convention distinguishes dif¬ 
ferent kinds of files, usually with filename 
extensions (such as memo.txt). Star re¬ 
lieves users of the need to keep track of 
which data file goes with which applica- 

SunView is an example of a window 
system based upon the Tools metaphor 
rather than the Desktop metaphor. Its users 
see a collection of application program 
windows, each used to edit certain files. 
Smalltalk-80, Cedar, and various Lisp 
environments also use the Tools metaphor 
rather than the Desktop metaphor. 

This is not to say that the Desktop meta¬ 
phor is superior to the Tools metaphor. The 
Desktop metaphor targets office automa¬ 
tion and publishing. It might not suit other 
applications (such as software develop¬ 
ment). However, we could argue that ori¬ 
enting users toward their data rather than 
toward application programs and employ¬ 
ing analogies with the physical world are 
useful techniques in any domain. 

The disadvantage of assigning data files 


to applications is that users sometimes 
want to operate on a file with a program 
other than its “assigned” application. 
Such cases must be handled in Star in an ad 
hoc way, whereas systems like Unix allow 
you to run almost any file through a wide 
variety of programs. Star’s designers feel 
that, for its audience, the advantages of 
allowing users to forget about programs 
outweighs this disadvantage. 

Generic commands. One way to sim¬ 
plify a computer system is to reduce the 
number of commands. Star achieves sim¬ 
plicity without sacrificing functionality 
by having a small set of generic commands 
apply, to all types of data: Move, Copy, 
Open, Delete, Show Properties, and Same 
(Copy Properties). Dedicated function 
keys on Star’s keyboard invoke these 
commands. Each type of data object inter¬ 
prets a generic command in a way appro¬ 
priate for it. 

Such an approach avoids the prolifera¬ 
tion of object-specific commands and/or 
command modifiers found in most sys¬ 
tems, such as Delete Character, Delete 
Word, Delete Line, Delete Paragraph, and 
Delete File. Command modifiers are nec¬ 


essary in systems in which selection is 
only approximate. Consider the many 
systems in which the object of a command 
is specified by a combination of the cursor 
location and the command modifier. For 
example, Delete Word means “delete the 
word that the cursor is on.” 

Modifiers are unnecessary in Star be¬ 
cause exact selection of the objects of 
commands is easy. In many systems, the 
large number of object-specific com¬ 
mands is made even more confusing by 
using single-word synonyms instead of 
command modifiers for similar opera¬ 
tions on different objects. For example, 
depending upon whether the object of the 
command is a file or text, the command 
used might be Remove or Delete, Dupli¬ 
cate or Copy, and Find or Search, respec¬ 
tively. 

Careful choice of the generic com¬ 
mands can further reduce the number of 
commands required. For example, you 
might think it necessary to have a generic I 

command Print for printing various 
things. Having Print apply to all data ob¬ 
jects would avoid the trap that some sys¬ 
tems fall into of having separate com¬ 
mands for printing documents, spread- 


Direct manipulation 

Jeff Johnson and Teresa L. Roberts 

Star’s Desktop metaphor is based upon the more general 
principle of “direct manipulation." 12 What, exactly, is direct 
manipulation? Consider the following passage from a descrip¬ 
tion of Apple’s Macintosh: 

Imagine driving a car that has no steering wheel, accelerator, 
brake pedal, turn signal lever, or gear selector. In place of all the 
familiar manual controls, you have only a typewriter keyboard. 

Anytime you want to turn a corner, change lanes, slow down, 
speed up, honk your horn, or back up, you have to type a command 
sequence on the keyboard. Unfortunately, the car can't understand 
English sentences. Instead, you must hold down a special key with 
one finger and type in some letters and numbers, such as 
“S20:TL:A35," which means, “Slow to 20, turn left, and accelerate 
to 35." 

No doubt you could learn to drive such a car if you had sufficient 
motivation and determination. But why bother, when so many cars 
use familiar controls? Most people wouldn’t. 3 

Actually, it isn’t familiarity that makes real cars easier to 
drive than the hypothetical "computer car" would be — cars 
are certainly not familiar to those who are just learning to drive 
them. What makes real cars easier to drive is the directness of 
their controls. Real cars have distinct interfaces to the speed 
control (the accelerator pedal), the direction control (the steer¬ 
ing wheel), the gears (the gearshift handle), the radio (several 
knobs and buttons), etc. Each interface is specially designed 
for controlling its respective function. In contrast, the hypo¬ 


thetical “computer-car" has only one control: a keyboard. 

Direct manipulation requires that distinct functions be in¬ 
voked and controlled in spatially distinct locations, in ways that 
are specific and appropriate for the particular function being 
controlled. Data objects should be selected and operated on 
by simulated physical contact rather than by abstract verbal 
reference: “ That one" rather than “The one in row 6.” Continu¬ 
ous functions (such as screen brightness and color saturation) 
should be controlled via continuous controls such as sliders, 
knobs, and dials. Discrete functions (such as character font 
family) should be controlled via discrete means such as com¬ 
mands, multiposition switches, or menus. In effect, a direct 
manipulation system has a different input channel for every 
function the user can have it perform. 

Conventional interfaces are indirect in that there is a single, 
general interface to all functionality (such as a keyboard and 
command language or a menu). In other words, there is only 
one input channel for all kinds of input; different kinds of input 
are distinguished linguistically, rather than spatially. 

Having a different interface to each function may seem to 
contradict the goal of having a consistent interface, but in fact 
does not. Similar functions should indeed have similar user in¬ 
terfaces across contexts. Direct manipulation requires, how¬ 
ever, that different functions should have distinct interfaces, 
just as a car has distinct interfaces to its various functions. 

Directness versus indirectness is not a simple dichotomy: 
we can speak of degrees of directness. Consider a graphics 
editor for creating illustrations. In the following sequence of in¬ 
terfaces, each contains all of the indirection of the previous 
one and adds a new level: 
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sheets, illustrations, directories, etc., but 
it is nonetheless unnecessary. In Star, us¬ 
ers simply Copy to a printer icon whatever 
they want to print. Similarly, the Move 
command is used to invoke Send Mail by 
moving a document to the out-basket. 

Of course, not everything can be done 
via generic commands. Some operations 
are object-specific. For example, a word 
might use italics, but italics are meaning¬ 
less for a triangle. In Star, object-specific 
operations are provided via selection- 
dependent “soft” function keys and via 
menus attached to application windows. 

Direct manipulation and graphical 
user interface. Traditional computer sys¬ 
tems require users to remember and type a 
great deal just to control the system. This 
impedes learning and retention, espe¬ 
cially by casual users. Star’s designers 
favored an approach emphasizing recog¬ 
nition over recall, seeing and pointing 
over remembering and typing. This sug¬ 
gested using menus rather than com¬ 
mands. However, the designers wanted to 
go beyond a conventional menu-based 
approach. They wanted users to feel that 
they are manipulating data directly, rather 


than issuing commands to the system to do 
it. Star’s designers also wanted to exploit 
the tremendous communication possibili¬ 
ties of the display. They wanted to move 
away from strictly verbal communica¬ 
tion. Therefore, they based the system 
heavily upon principles that are now 
known as direct manipulation and graphi¬ 
cal control. 

Star users control the system by manipu¬ 
lating graphical elements on the screen, 
elements that represent the state of the sys¬ 
tem and data created by users. The system 
does not distinguish between input and 
output. Anything displayed (output) by 
the system can be pointed to and acted upon 
by the user (input). When Star displays a 
directory, it (unlike MS-DOS and Unix) is 
not displaying a list of the names of the files 
in the directory, it is displaying the files 
themselves so that the user can manipulate 
them. Users of this type of system have the 
feeling that they are operating upon the 
data directly, rather than through an agent 
— like fetching a book from a library shelf 
yourself rather than asking someone to do 
it for you. 

A related principle is that the state of the 
system always shows in the display. Noth¬ 


ing happens “behind the user’s back.” 
You needn’t fiddle with the system to un¬ 
derstand what’s going on; you can under¬ 
stand by inspection. 

One of Star’s designers wrote 

When everything in a computer system is 
visible on the screen, the display becomes 
reality. Objects and actions can be under¬ 
stood purely in terms of their effects upon the 
display. This vastly simplifies understand¬ 
ing and reduces learning time. 1 2 3 4 

An example of this philosophy is the fact 
that, unlike many window-based com¬ 
puter systems (even some developed at 
Xerox), Star has no hidden menus — all 
available menus are marked with menu 
buttons. 

For a more detailed explanation of di¬ 
rect manipulation, see the sidebar. 

Icons and iconic file management. 
Computer users often have difficulty 
managing their files. Before Star existed, 
a secretary at Xerox complained that she 
couldn’t keep track of the files on her disk. 
An inspection of her system revealed files 
named memo, memol, memo071479, let¬ 
ter, etc. Naming things to keep track of 


(1) The most direct interlace for moving a circle would have 
the user point directly at the screen and pull the circle to its new 
location. 

(2) Introducing a mouse, bitpad, or joystick adds one level of 
indirection: moving the mouse, bitpad stylus, or joystick on the 
desk moves the pointer on the screen. Some users have diffi¬ 
culty with this indirection. 

(3) Arrow keys introduce another level — and another kind — 
of indirection: the keystroke movements required to move the 
screen pointer, and hence the circle, do not resemble the de¬ 
sired movement of the circle. 

(4) Typing a command to move the circle is still more indirect. 
Though typing a command involves movements (keystrokes), 
we are inclined to think of the movements as incidental; they 
could just as well be speech. Thus, it is no longer a matter of 
movement — similar or not — in one place corresponding to 
movement in another place; rather, it is the syntax and seman¬ 
tics of the command that determine what happens. 

Differences in directness can be very subtle. Contrast the 
following two methods of changing the size of a window on the 
display: 

(1) Grabbing onto a corner of the window and stretching the 
window to the desired size. 

(2) Clicking on the desired window, choosing Resize from a 
command pull-down menu, then pointing to where the win¬ 
dow’s new border is to be moved. 

It is sometimes said that mouse-driven user interfaces are 
direct while keyboard user interfaces are indirect. Note, how¬ 
ever, that both methods 1 and 2 above use a mouse, yet 


method 2 is less direct than method 1. 

The above examples involve an illustration tool and a win¬ 
dow manager. Such applications are actually in a special cate¬ 
gory with respect to direct manipulation, because the images 
on the screen are what the application is intended to manipu¬ 
late. The purpose of many applications (such as databases, 
command and control, and file management) is to allow users 
to manipulate information that is only represented on the 
screen in some way (for example, pictorially or textually). Such 
applications therefore have one inherent level of indirection. 

Systems having direct-manipulation user interfaces encour¬ 
age users to think of them as tools rather than as assistants, 
agents, or coworkers. Natural-language user interfaces, 
which are inherently indirect, encourage the reverse. As direct- 
manipulation interfaces become more prevalent and as pro¬ 
gress is made in natural-language understanding and genera¬ 
tion, it will be interesting to see which way users prefer to think 
about their computers. 
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them is bothersome enough for program¬ 
mers, but completely unnatural for most 
people. 

Star alleviates this problem partly by 
representing data files with pictures of 
office objects called icons. Every applica¬ 
tion data file in the system has an icon rep¬ 
resenting it. Each type of file has a charac¬ 
teristic icon shape. If a user is looking for a 
spreadsheet, his or her eye can skip over 
mailboxes, printers, text documents, etc. 

Furthermore, Star allows users to or¬ 
ganize files spatially rather than by dis¬ 
tinctive naming. Systems having hierar¬ 
chical directories, such as Unix and MS- 
DOS, provide an abstract sort of “spatial” 
file organization, but Star’s approach is 
concrete. Files can be kept together by 
putting them into a folder or simply by 
clumping them together on the Desktop, 
which models how people organize their 
physical worlds. Since data files are repre¬ 
sented by icons, and files are distinguished 
by location and specified by selection 
rather than by name, users can use names 
like memo, memol, letter, etc., without 
losing track of their files as easily as they 
would with most systems. 

As bitmap-, window-, and mouse-based 
systems have become more common, the 
use of the term “icon” has widened to re¬ 
fer to any nontextual symbol on the dis¬ 
play. In standard English, “icon” is a term 
for religious statues or pictures believed to 
contain some of the powers of the deities 
they represent. It would be more consis¬ 
tent with its normal meaning if “icon” 
were reserved for objects having behav¬ 
ioral and intrinsic properties. Most gra¬ 
phical symbols and labels on computer 
screens are therefore not icons. In Star, 
only representations of files on the Desk¬ 
top and in folders, mailboxes, and file 
drawers are called icons. 

Few modes. A system has modes if user 
actions differ in effects or availability in 
different situations. Tesler has argued that 
modes in interactive computer systems 
are undesirable because they restrict the 
functions available at any given point and 
force users to keep track of the system’s 
state to know what effect their actions will 
have. 3 Though modes can be helpful in 
guiding users through unfamiliar proce¬ 
dures or for handling exceptional activi¬ 
ties, they should be used sparingly and 
carefully. 

Star avoids modes in several ways. One 
is the extensive use of generic commands 
(see above), which drastically reduces the 
number of commands needed. This, in 


turn, means that designers need not assign 
double-duty (that is, different meanings in 
different modes) to physical controls. 

A second way is by allowing applica¬ 
tions to operate simultaneously. When 
using one program (such as a document 
editor), users are not in a mode that pre¬ 
vents them from using the capabilities of 
other programs (such as the desktop man¬ 
ager). 

A third way Star avoids modes is by us¬ 
ing a noun-verb command syntax. Users 
select an operand (such as a file, a word, or 
a table), then invoke a command. In con¬ 
ventional systems, arguments follow 
commands, either on a command line or in 
response to prompts. Whether a system 
uses noun-verb or verb-noun syntax has a 
lot to do with how moded it is. In a noun¬ 
verb system such as Star, selecting an ob¬ 
ject prior to choosing a command does not 
put the system into a mode. Users can de¬ 
cide not to invoke the command without 
having to “escape out” of anything or can 
select a different object to operate on. 

Though Star avoids modes, it is not 
completely modeless. For example, the 
Move and Copy commands require two 
arguments: the object to be moved and the 
final destination. Though less moded 
ways to design Move and Copy exist, these 
functions currently require the user to se¬ 
lect the object, press the Move or Copy key, 
then indicate the destination using the 
mouse. While Star waits for the user to 
point to a destination, it is in Move or Copy 
mode, precluding other uses of the mouse. 
These modes are relatively harmless, 
however, because (1) the shape of the cur¬ 
sor clearly indicates the state of the system 
and (2) the user enters and exits them in the 
course of carrying out a single mental plan, 
making it unlikely that the system will be 
in the ‘ ‘wrong’ ’ mode when the user begins 
his or her next action. 

Objects have properties. Properties 
allow objects of the same type to vary in 
appearance, layout, and behavior. For 
example, files have a Name property, char¬ 
acters have a Font family property, and 
paragraphs have a Justified property. 
Properties may have different types of val¬ 
ues: the Name property of a file is a text 
string; the Size property of a character 
might be a number or a choice from a menu; 
the Justified property of a paragraph is ei¬ 
ther “on” or “off.” In Star, properties are 
displayed and changed in graphical forms 
called property sheets. 

Property-based systems are rare. Most 
computer systems, even today, allow us¬ 


ers to set parameters for the duration of an 
interactive session or for the duration of a 
command, but not for particular data ob¬ 
jects. For example, headings in Wordstar 
documents do not “remember” whether 
they are centered or not; whether a line is 
centered is determined by how the pro¬ 
gram was set when the line was typed. 
Similarly, directories in Unix do not 
“remember” whether files are to be listed 
in alphabetical or temporal order; users 
must respecify which display order 
they want every time they invoke the Is 
command. 

Progressive disclosure. It has been said 
that “computers promise the fountains of 
utopia, but only deliver a flood of informa¬ 
tion.” 4 Indeed, many computer systems 
overwhelm their users with choices, com¬ 
mands to remember, and poorly organized 
output, much of it irrelevant to what the 
user is trying to do. They make no presump¬ 
tions about what the user wants. Thus, they 
are designed as if all possible user actions 
were equally likely and as if all informa¬ 
tion generated by the system were of equal 
interest to the user. Some systems dimin¬ 
ish the problem somewhat by providing 
default settings of parameters to simplify 
tasks expected to be common. 

Star goes further towards alleviating 
this problem by applying a principle called 
“progressive disclosure.” Progressive 
disclosure dictates that detail be hidden 
from users until they ask or need to see it. 
Thus, Star not only provides default set¬ 
tings, it hides settings that users are un¬ 
likely to change until users indicate that 
they want to change them. Implicit in this 
design tire assumptions about which prop¬ 
erties will be less frequently altered. 

One place progressive disclosure is 
used is in property sheets. Some objects 
have a large number of properties, many of 
which are relevant only when other prop¬ 
erties have certain values (see Figure 2). 
For example, on the page layout property 
sheet, there is no reason to display all of the 
properties for specifying running header 
content and position unless the user actu¬ 
ally specifies that the document will have 
running headers. 

Another example of progressive disclo¬ 
sure is the fact that property displays in 
Star are temporary, displayed on demand. 
In some systems, the properties of the cur¬ 
rent selection are displayed at all times, 
through codes embedded in the text or in an 
area of the screen reserved for that pur¬ 
pose, even though the user usually doesn’t 
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Figure 2. Progressive disclosure. Star’s property sheets, like the rest of the interface, use a principle known as progressive 
disclosure to avoid overwhelming users with information. Usually, users don’t need to see an object’s properties: they only 
need to see and perhaps change its assigned style. Users see an object’s properties only upon request. Also, even when a user 
sets a property sheet to show an object’s properties, as shown here, some information remains hidden until the user asks to 
see it. For example, there is no need to clutter the property sheet here with boxes for entering numbers for “Other” values of 
Line Height, Spacing Before Paragraph, or Spacing After Paragraph until the user actually sets the property to “Other.” 


A highly refined manifestation of pro¬ 
gressive disclosure recently added to 
ViewPoint is styles, which allows users to 
regard document content (such as a para¬ 
graph) as having a single style rule instead 
of a large number of properties. Thus, 
styles hide needless detail from users. 

Consistency. Because Star and all of its 
applications were designed and devel¬ 
oped in-house, its designers had more con¬ 
trol over its user interface than is usually 
the case with computer systems. Because 
the designers paid close attention to detail, 
they achieved a very high degree of consis¬ 
tency. The left mouse button always se¬ 
lects; the right always extends the selec¬ 
tion. Mouse-sensitive areas always give 
feedback when the left button goes down, 
but never take effect until the button comes 
up. 


Emphasis on good graphic and screen 
design. Windows, icons, and property 
sheets are useless if users can’t easily dis¬ 
tinguish them from the background or 
each other, can’t easily see which labels 
correspond to which objects, or can’t cope 
with the visual clutter. To assure that Star 
presents information in a maximally per¬ 
ceivable and useful fashion, Xerox hired 
graphic designers to determine the ap¬ 
pearance and placement of screen objects. 
These designers applied various written 
and unwritten principles to the design of 
the window headers and borders, the Desk¬ 
top background, the command buttons, 
the pop-up menus, the property sheets, and 
the Desktop icons. The most important 
principles are 

• The illusion of manipulate objects. 
One goal, fundamental to the notion of di¬ 


rect manipulation, is to create the illusion 
of manipulate objects. It should be clear 
that objects can be selected and how to se¬ 
lect them. It should be obvious when they 
are selected and that the next action will 
apply to them. Whereas the usual task of 
graphic designers is to present informa¬ 
tion for passive viewing, Star’s designers 
had to figure out how to present informa¬ 
tion for manipulation as well. This shows 
most clearly in the Desktop icons, with 
their clear figure/ground relationship: the 
icons stand by themselves, with self-con¬ 
tained labels. Windows reveal in their bor¬ 
ders the “handles” for scrolling, paging, 
window-specific commands, and pop-up 
menus. 

• Visual order and user focus. One of the 
most obvious contributions of good 
graphic design is appropriate visual order 
and focus on the screen. For example, in- 
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Figure 3. Visual order and user focus. The large amount of contrast present on the screens of many window systems (left 
screen) makes it difficult to focus on the relevant information. The selection should be the user’s main focus: it is the object of 
the next operation. The right screen shows how Star/ViewPoint’s screen design focuses attention on the selection. 



Figure 4. Visual order and user focus. Four candidate sets of icons were designed 
and tested for Star. A representative sample from each set is shown here. In Star, 
the icon selected by the user is indicated by inverting its image. Candidate icon 
sets in which the images are mostly white allow icons to stand out when selected. 
The set that best satisfies this criterion, the one on the upper left, was chosen. 


tensity and contrast, when appropriately 
applied, draw the user’s attention to the 
most important features of the display. 

In some windowing systems, window 
interiors have the same (dark) color as the 
Desktop background. Window content 
should have high intensity relative to the 
Desktop, to draw attention to what is im¬ 
portant on the screen. In Star, window con¬ 
tent background is white, both for high 
contrast and to simulate paper. 

Star keeps the amount of black on the 
screen to a minimum to make the selection 
stand out (see Figure 3). In most window¬ 
ing systems, window headers and other 
areas of the screen are black, making the 
selection hard to find. This principle is so 
important that Star’s designers made sure 
that the display hardware could fill the 
nonaddressable border of the screen with 
Desktop grey rather than leaving it black as 
in most systems. Star also uses icon images 
that turn from mostly white to mostly black 
when selected (see Figure 4) and allows at 
most one selection on the screen at a time. 

• Revealed structure. Often, the more 
powerful the program used, the greater the 
distance between intention and effect. If 
only effect is displayed and not intention, 
the user’s task of learning the connection 
is much more difficult. A good graphical 
interface can make apparent to the user 
these connections between intention and 
effect, that is, “revealed structure.” For 
example, there are many ways to deter¬ 
mine the position and length of a line of text 
on a page. It can be done with page margins, 
paragraph indentations, centering, tabs, 
blank lines, or spaces. The WYSIWYG, or 
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Figure 5. Revealed structure. At the top is the WYSIWYG view of mixed text and 
graphics. The middle two panels show that structure is revealed when an object is 
selected. When a line segment is selected, its control points are shown. When text 
is selected, the text string is revealed. The bottom panel shows the effect of the 
Show Structure and Show Non-Printing Characters commands, which is to re¬ 
veal the location of embedded graphics and text frames (dotted lines) and “new 
paragraph” and Space characters. 


“what you see is what you get,” view of all 
these would be identical. That would be 
enough if all that mattered to the user was 
the final form on paper. But what will hap¬ 
pen if characters are inserted? If the line is 
moved to another page, where will it land? 
WYSIWYG views are sometimes not 
enough. 

Special views are one method of reveal¬ 
ing structure. In Star, documents can show 
“Structure” and/or “Non-Printing Char¬ 
acters” if desired (see Figure 5). Another 
convenient means for revealing structure 
is to make it show up during selection. For 
example, when a rectangle is selected in a 
graphics frame, eight control points high¬ 
light it, any of which can attach to the cur¬ 
sor during Move or Copy and can land on 
grid points for precise alignment. The 
control point highlighting allows a user to 
distinguish a rectangle from four straight 
lines; both might produce the same printed 
effect but would respond differently to 
editing. 

• Consistent and appropriate graphic 
vocabulary. Property sheets (see Figure 2) 
present a form-like display for the user to 
specify detailed property settings and ar¬ 
guments to commands. They were de¬ 
signed with a consistent graphic vocabu¬ 
lary. All of the user’s targets are in boxes; 
unchangeable information such as a prop¬ 
erty name is not. Mutually exclusive val¬ 
ues within choice parameters appear with 
boxes adjacent. Independent “on/off” or 
state parameters appear with boxes sepa¬ 
rated. The current settings are shown in¬ 
verted. Some of the menus display graphic 
symbols rather than text. Finally, there are 
text parameters consisting of a box into 
which text or numbers can be typed, cop¬ 
ied, or moved, and within which text edit¬ 
ing functions are available. 

• Match the medium. It is in this last prin¬ 
ciple that the sensitivities of a good 
graphic designer are most apparent. The 
goal is to create a consistent quality in the 
graphics that is appropriate to the product 
and makes the most of the given medium. 
Star has a large black and white display. 
The solutions the graphics designers de¬ 
vised might have been very different had 
the display had grey-scale or color pixels. 

A common problem with raster displays 
is “jaggies”: diagonal lines appearing as 
staircases. With careful design, jaggies 
can be avoided, for example, by using only 
vertical, horizontal, and 45-degree 
angles. Also important is controlling how 
the edges of the figures interact with the 
texture of the ground. Figure 6 shows how 
edges are carefully matched to the back¬ 


ground texture so that they have a consis¬ 
tent quality appearance. 

Document editor level. At the top level 
of Star’s architecture are its applications, 
the most prominent of which is the docu¬ 
ment editor. 

WYSIWYG document editor. Within the 
limits of screen resolution. Star docu¬ 
ments are displayed as they will print, in¬ 
cluding typographic features such as bold¬ 
face, italics, proportional spacing, vari¬ 
able font families, and superscripts, and 
layout features such as embedded graph¬ 
ics, page numbers, headers, and footers. 
This is commonly referred to as “what you 
see is what you get,” or WYSIWYG. 

Star adheres to this principle even in 
domains where other WYSIWYG docu¬ 
ment editors do not. For example, mathe¬ 
matical formulas are created and edited in 
documents using a WYSIWYG editor that 
has knowledge built into it about the ap¬ 
pearance and layout of mathematical sym¬ 
bols. A square root sign has a slot for an 
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Figure 6. Match the medium. Many 
graphic refinements were made during 
the design process. For example, the 
turned corner of the document icon 
was moved to the top so that the three 
lines of label would line up with the la¬ 
bels of other icons. Also, icons were 
carefully sized and positioned against 
the gray background to create 
smoother lines. 
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expression and grows when the expres¬ 
sion becomes large (see Figure 7). In most 
systems, mathematical formulas are cre¬ 
ated either by putting together special 
characters to make mathematical symbols 
or by using a special in-line notation (such 
as sqrt(sigma(l, n, (x*3)/2))) to represent 
the formula that will eventually be printed. 
Formulas created with such systems usu¬ 
ally require several print-edit cycles to get 
right. 

Extended character set for multilingual 
capability. Star uses 16-bit character 
codes, in contrast to most of the computer 
industry, which uses seven- or eight-bit 
character codes (for example, ASCII or 
EBCDIC). The Star character set is a su¬ 
perset of ASCII. The reason for a 16-bit 
code is a strong market requirement for 
enhanced multilingual capabilility com¬ 
ing from Xerox’s subsidiaries in Europe 
and Japan. Most systems provide non- 
English characters through different 
fonts, so that the eight-bit “extended” 
ASCII codes might be rendered as math 
symbols in one font, Greek letters in an¬ 
other font, and Arabic in yet another. This 
has the effect that when any application 
loses track of font information while han¬ 
dling the text (which happens often in 
some systems), a paragraph of Arabic may 
turn into nonsensical Greek or math sym¬ 
bols or something else, and vice versa. 

Star uses 16-bit character codes to per¬ 
mit the system to reliably handle European 
languages and Japanese, which uses many 
thousands of characters. All Star and 
Viewpoint systems have French, German, 
Italian, Spanish, and Russian language 
capabilities built in. The Japanese lan¬ 
guage capability was developed as part of 
the original Star design effort and released 
in Japan soon after Star’s debut in the 
United States. Since that time, many more 
characters have been added, covering Chi¬ 
nese, Arabic, Hebrew, and nearly all Euro¬ 
pean languages. 

As explained in several articles by Joe 
Becker, the designer of Star’s multilin¬ 
gual capabilities, handling many of the 
world’s languages requires more than an 
expanded character set. 5 Clever typing 
schemes and sophisticated rendering al¬ 
gorithms are required to provide a multi¬ 
lingual capability that satisfies customers. 

The document is the heart of the world 
and unifies it. Most personal computers 
and workstations give no special status to 
any particular application. Dozens of ap¬ 
plications are available, most incompat¬ 


ible with each other in data format as well 
as user interface. 

Star, in contrast, assumes that the pri¬ 
mary use of the system is to create and 
maintain documents. The document edi¬ 
tor is thus the primary application. All 
other applications exist mainly to provide 
or manipulate information whose ulti¬ 
mate destination is a document. Thus, 
most applications are integrated into the 
document editor (see “Integrated appli¬ 
cations” above), operating within frames 
embedded in documents. Those applica¬ 
tions that are not part of the document 
editor support transfer of their data to 
documents. 

History of Star 
development 

Having described Star and ViewPoint, 
we will describe where they came from and 
how they were developed. Figure 8 graphs 
this history, showing systems that influ¬ 
enced Star and those influenced by it. 

Pre-Xerox. Although Star was con¬ 
ceived as a product in 1975 and was re¬ 
leased in 1981, many of the ideas that went 
into it were bom in projects dating back 
more than three decades. 

Memex. The story starts in 1945, when 
Vannevar Bush, a designer of early calcu¬ 
lators and one of President Franklin D. 
Roosevelt’s science advisors, wrote an 
article describing his vision of the uses of 
electronics and information technology. 
At a time when computers were new, 
room-sized, and used only for military 
number-crunching, Bush envisioned a 
personal, desktop computer for non-nu- 
merical applications. He called it the 
Memex. Due to insufficient technology 
and insufficient imagination on the part of 
others, Bush’s ideas languished for 15 
years. 

Sketchpad. In the sixties, people began 
to take interactive computing seriously. 
One such person was Ivan Sutherland. He 
built an interactive graphics system called 
Sketchpad that allowed a user to create 
graphical figures on a CRT display using a 
light pen. The geometric shapes users put 
on the screen were treated as objects: after 
being created, they could be moved, cop¬ 
ied, shrunk, expanded, and rotated. They 
could also be joined together to make 
larger, more complex objects that could 
then be operated upon as units. Sketchpad 


influenced Star’s user interface as a whole 
as well as its graphics applications. 

NLS. Also in the sixties, Douglas Engel- 
bart established a research program at 
Stanford Research Institute (now called 
SRI International) for exploring the use of 
computers “to augment the knowledge 
worker” and human intellect in general. 
He and his collegues experimented with 
different types of displays and input de¬ 
vices (inventing the mouse when other 
pointing devices proved inadequate) and 
developed a system commonly known as 
NLS.* 

NLS was unique in several respects. It 
used CRT displays when most computers 
used teletypes. It was interactive (i.e., on¬ 
line) when almost all computing was 
batch. It was full-screen-oriented when 
the few systems that were interactive were 
line-oriented. It used a mouse when all 
other graphic interactive systems used 
cursor keys, light pens, joysticks, or digit¬ 
izing tablets. Finally, it was the first sys¬ 
tem to organize textual and graphical in¬ 
formation in trees and networks. Today, it 
would be called an “idea processor” or a 
“hypertext system.” 

The Reactive Engine. While Engelbart 
et al. were developing ideas, some of 
which eventually found their way into 
Star, Alan Kay, then a graduate student, 
was doing likewise. His dissertation. The 
Reactive Engine, contained the seeds of 
many ideas that he and others later brought 
to fruition in the Smalltalk language and 
programming environment, which, in 
turn, influenced Star. Like the designers of 
NLS, Kay realized that interactive appli¬ 
cations dp not have to treat the display as a 
“glass teletype” and can share the screen 
with other programs. 

Xerox PARC. In 1970, Xerox estab¬ 
lished a research center in Palo Alto to 
explore technologies that would be impor¬ 
tant not only for the further development of 
Xerox’s then-existing product line (copi¬ 
ers), but also for Xerox’s planned expan¬ 
sion into the office systems business. The 
Palo Alto Research Center was organized 
into several laboratories, each devoted to 
basic and applied research in a field related 
to the above goals. The names and organi- 


*The actual name of the system was On-Line System. 
A second system called Off-Line System was abbrevi¬ 
ated FLS, hence NLS's strange abbreviation. NLS is 
now marketed by McDonnell Douglas under the name 
Augment. 
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Figure 7. WYSIWYG formula editing. Mathematical formulas are edited in Star in a highly WYSIWYG fashion, in contrast 
to most systems, in which formulas are specified via in-line expressions or by constructing them from pieces in a special 
character font. 



one another over the years. Time progresses downwards. Double arrows indicate direct successors (i.e., foilow-on versions). 
Many “influence arrows” are due to key designers changing jobs or applying concepts from their graduate research to 
products. 
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cated to a vision of personal computers in a 
distributed environment. In fact, they 
coined the term “personal computer’’ in 
1973, long before microcomputers started 
what has been called the “personal com¬ 
puter revolution.” 

One result of the search for a new ap¬ 
proach was the Alto (see Figure 9). The 
Alto was a minicomputer that had a remov¬ 
able, 2.5-megabyte hard disk pack (floppy 
disks did not exist at the time) and 128 to 
256 kilobytes of memory. Unlike most 
machines of its day, the Alto also had a 
microprogrammable instruction set, a 
“full-page” (1014 x 814 inch, 600 x 800 
pixel) bitmapped graphic display, about 
50 kilobytes of high-speed display mem¬ 
ory, and a mouse. 

The first Alto became operational in 
1972. At first, only a half-dozen or so Al¬ 
tos were built. After software that ex¬ 
ploited the Alto’s capabilities became 
available, demand for them grew tremen¬ 
dously, spreading beyond PARC into 
Xerox as a whole and even to external cus¬ 
tomers. Eventually, Xerox built more than 
a thousand Altos. 

Ethernet. Another product of the new 
approach was the Ethernet. With its stan¬ 
dardized, layered communications proto¬ 
cols, Ethernet provided a way of connect¬ 
ing computers much more flexibly than 
previously possible. Soon after the first 
Altos were built, they were networked 
together. Eventually, the network grew to 
thousands of workstations (Altos and Alto 
successors) within Xerox’s worldwide 
organization. 

Smalltalk. Alan Kay was one of the main 
advocates of the Alto. His Learning Re¬ 
search Group began using the Alto to build 
prototypes for a personal computing sys¬ 
tem “of the future” — a portable machine 
that would provide not canned applica¬ 
tions but rather the building blocks neces¬ 
sary for users to build the tools and appli¬ 
cations they needed to solve their own in¬ 
formation processing problems. The tech¬ 
nologies needed to build a lap computer 
with the power of the envisioned system 
(called the “DynaBook”) were unavail¬ 
able at the time and still are. 

The prototypes developed by Kay’s 
group evolved into the Smalltalk language 
and programming environment. Small¬ 
talk further promoted the notion of per¬ 
sonal computing; pioneered complete, 
interactive programming environments; 
and refined and solidified concepts of ob¬ 
ject-oriented programming that had been 


Figure 9. The Xerox Alto. The Alto, developed at Xerox PARC in the seventies, 
was a prototype for Star. Both its hardware design and the many programs writ¬ 
ten for it by PARC researchers strongly influenced Star’s designers. 


zation of the labs have changed over the 
years, but the research topics have stayed 
the same: materials science, laser physics, 
integrated circuitry, computer-aided de¬ 
sign and manufacturing, user interfaces 
(not necessarily to computers), and com¬ 
puter science (including networking, da¬ 
tabases, operating systems, languages 
and programming environments, graph¬ 
ics, document production systems, and 
artificial intelligence). 

Alto. PARC researchers were fond of the 


slogan “The best way to predict the future 
is to invent it.” After some initial experi¬ 
ments with time-shared systems, they 
began searching for a new approach to 
computing. 

Among the founding members of PARC 
was Alan Kay. He and his colleagues were 
acquainted with NLS and liked its novel 
approach to human-computer interaction. 
Soon, PARC hired several people who had 
worked on NLS. In 1971, the center signed 
an agreement with SRI licensing Xerox to 
use the mouse. Kay and others were dedi¬ 
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extant only in vestigial forms in previous 
systems. Most importantly for Star, 
Smalltalk demonstrated the power of gra¬ 
phical, bitmapped displays; mouse- 
driven input; windows; and simultaneous 
applications. This is the most visible link 
between Smalltalk and Star, and is perhaps 
why many people wrongly believe that 
Star was written in Smalltalk. 

Pygmalion. The first large program to 
be written in Smalltalk was Pygmalion, the 
doctoral thesis project of David C. Smith. 
One goal of Pygmalion was to show that 
programming a computer does not have to 
be primarily a textual activity. It can be 
accomplished, given the appropriate sys¬ 
tem, by interacting with graphical ele¬ 
ments on a screen. A second goal was to 
show that computers can be programmed 
in the language of the user interface, that is, 
by demonstrating what you want done and 
having the computer remember and repro¬ 
duce it. The idea of using icons — images 
that allow users to manipulate them and in 
so doing act upon the data they represent— 
came mainly from Pygmalion. After com¬ 
pleting Pygmalion, Smith worked briefly 
on the NLS project at SRI before joining 
the Star development team at Xerox. 

Bravo, Gypsy, and BravoX. At the same 
time that the Learning Research Group 
was developing Smalltalk for the Alto, 
others at PARC, mainly Charles Simonyi 
and Butler Lampson, were writing an ad¬ 
vanced document editing system for it 
called Bravo. Because it made heavy use of 
the Alto’s bitmapped screen, Bravo was 
unquestionably the most WYSIWYG text 
editor of its day, with on-screen underlin¬ 
ing, boldface, italics, variable font fami¬ 
lies and sizes, and variable-width charac¬ 
ters. It allowed the screen to be split, so 
different documents or different parts of 
the same document could be edited at once, 
but did not operate in a windowed environ¬ 
ment as we use the term today. Bravo was 
widely used at PARC and in Xerox as a 
whole. 

From 1976 to 1978, Simonyi and others 
rewrote Bravo, incorporating many of the 
new user-interface ideas floating around 
PARC at the time. One such idea was 
modelessness, promoted by Larry Tesler 1 
and exemplified in Tesler’s prototype text 
editor, Gypsy. Simonyi et al. also added 
styles, enhancing users’ ability to control 
the appearance of their documents. The 
new version was called BravoX. 

Shortly thereafter, Simonyi joined Mi¬ 
crosoft, where he led the development of 


Microsoft Word, a direct descendent of 
BravoX. Another member of the BravoX 
team, Tom Malloy, went to Apple and 
wrote LisaWrite. 

Draw, Sil, Markup, Flyer, and Doodle. 
Star’s graphics capability (its provisions 
for users to create graphical images for 
incorporation into documents, as opposed 
to its graphical user interface) owes a great 
deal to several graphics editors written for 
the Alto and later machines. 

Draw, by Patrick Beaudelaire and Bob 
Sproull, and Sil (for Simple Illustrator) 
were intellectual successors of Suther¬ 
land’s Sketchpad (see above): graphical 
object editors that allowed users to con¬ 
struct figures out of selectable, movable, 
stretchable geometric forms and text. In 
turn, Star’s graphic frames capability is in 
large measure an intellectual successor of 
Draw and Sil. 

Markup was a bitmap graphics editor 
(that is, a paint program) written by Wil¬ 
liam Newman for the Alto. Flyer was an¬ 
other paint program, written in Smalltalk 
for the Alto by Bob Flegel and Bill Bow¬ 
man. These programs inspired Doodle, a 
paint program written for a later machine 
by Dan Silva. Doodle eventually evolved 
into Viewpoint’s Free-Hand Drawing 
application. Silva went on to write De- 
luxePaint, a paint program for PCs. 

Laser printing. Fancy graphics capa¬ 
bilities in a workstation are of little use 
without hard-copy capability to match it. 
Laser printing, invented at PARC, pro¬ 
vided the necessary base capability, but 
computers needed a uniform way to de¬ 
scribe output to laser printers. For this pur¬ 
pose, Bob Sproull developed the Press 
page-description language. Press was 
heavily used at PARC, then further devel¬ 
oped into Interpress, Xerox’s commercial 
page-description language and the lan¬ 
guage in which Star encodes printer out¬ 
put. Some of the developers of Interpress 
later formed Adobe Systems and devel¬ 
oped Postscript, a popular page descrip¬ 
tion language. 

Laurel and Hardy. A network of per¬ 
sonal workstations suggests electronic 
mail. Though electronic mail was not in¬ 
vented at PARC, PARC researchers 
(mainly Doug Brotz) made it more acces¬ 
sible to nonengineers by creating Laurel, 
a display-oriented tool for sending, re¬ 
ceiving, and organizing e-mail. The expe¬ 
rience of using Laurel inspired others to 
write Hardy for an Alto successor ma¬ 


chine. Laurel and Hardy were instrumen¬ 
tal in getting nonengineers at Xerox to use 
e-mail. The use of e-mail spread further 
with the spread of Star and ViewPoint 
throughout Xerox. 

OfficeTalk. One more Alto program 
that influenced Star was OfficeTalk, a 
prototype office automation system writ¬ 
ten by Clarence (“Skip”) Ellis and Gary 
Nutt. OfficeTalk supported standard of¬ 
fice automation tasks and tracked jobs as 
they went from person to person in an or¬ 
ganization. Experience with OfficeTalk 
provided ideas for Star because of the two 
systems’ similar target applications. 

Summing up. The debt that Star owes to 
the Alto and its software is best summed up 
by quoting from the original designers, 
who wrote in 1982; 

Alto served as a valuable prototype for 
Star.... Alto users have had several thousand 
work-years of experience with them over a 
period of eight years, making Alto perhaps 
the largest prototyping effort in history. 
There were dozens of experimental pro¬ 
grams written for the Alto by members of the 
Xerox Palo Alto Research Center. Without 
the creative ideas of the authors of these sys¬ 
tems, Star in its present form would have been 
impossible.... In addition, we ourselves pro¬ 
grammed various aspects of the Star design 
on the Alto... 

Star. To develop Star and other office 
systems products, Xerox created the 
Systems Development Department. SDD 
was staffed by transferring people from 
other parts of Xerox, including PARC, as 
well as by hiring from outside. Thus, con¬ 
trary to what has often been stated in the 
industry press. Star was not developed at 
PARC, but rather in a separate product- 
development organization. 

When SDD was formed, a decision was 
made to use Mesa, an “industrial- 
strength” dialect of Pascal conceived at 
SRI and further developed at PARC, as the 
primary product programming language. 
SDD took over development and mainte¬ 
nance of Mesa from the Computer Science 
Laboratory at PARC, freeing CSL to de¬ 
velop Mesa’s research successor. Cedar. 

Star hardware. Star is often discussed 
as if it were a computer. In fact. Star is a 
body of software.* However, using the 


*The official name for Star was the Xerox 8010 Infor¬ 
mation System. The machine was called the 8000 Se¬ 
ries Network Systems Processor. Originally, “Star” 
was only an internal name. 
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name Star to refer to the machine is under¬ 
standable since the machine was designed 
in conjunction with the software to meet 
the needs of the software design. This is in 
sharp contrast to the usual approach, in 
which software is designed for existing 
computers. 

The 8000 Series workstation was based 
upon a microcoded processor designed 
within Xerox especially to run the object 
code produced by the Mesa compiler. Be¬ 
sides being microprogrammed to run 
Mesa, the processor provided low-level 
operations for facilitating display opera¬ 
tions. For example, the bitblt operation for 
manipulating rectangular arrays of screen 
pixels is implemented as a single instruc¬ 
tion. As sold, the machine was configured 
with at least 384 kilobytes of real memory 
(expandable to 1.5 megabytes), a local 
hard disk (10, 29, or 40 megabytes), a 17- 
inch display, a mechanical mouse, an 
eight-inch floppy disk drive, and an Eth¬ 
ernet connection. The price was initially 
$16,500 with software. 

Even though the machine was designed 
to run Star, it also ran other software. In 
addition to selling it as the 8010 “Star” 
workstation, Xerox sold it as a server ma¬ 
chine and as an Interlisp and a Smalltalk 
workstation. 

Star software. Alhough Star incorpo¬ 
rated ideas from a number of predecessors, 
it still required a mammoth design effort to 
pull all of those ideas — as well as new 
ideas — together to produce a coherent 
design. According to the original design¬ 
ers, “. . . it was a real challenge to bring 
some order to the different user interfaces 
on the Alto.” 1 About 30 person-years went 
into the design of the user interface, func¬ 
tionality, and hardware. 

To foster uniformity of specifications 
as well as thoughtful and uniform design. 
Star’s designers developed a strict format 
for specifications. Applications and sys¬ 
tem features were to be described in terms 
of the objects that users would manipulate 
with the software and the actions that the 
software provided for manipulating ob¬ 
jects. This “objects and actions” analysis 
was supposed to occur at a fairly high level, 
without regard to how the objects would 
actually be presented or how the actions 
would actually be invoked by users. A full 
specification was then written from the 
“objects and actions” version. This ap¬ 
proach forced designers to think clearly 
about the purpose of each application or 
feature and fostered recognition of similar 
operations across specifications, allow¬ 


ing what might have seemed like new op¬ 
erations to be handled by existing com¬ 
mands. 

When SDD was formed, it was split be¬ 
tween two locations: Southern California 
(El Segundo) and Northern California 
(Palo Alto). Few people were willing to 
transfer one way or the other, leaving SDD 
with the choice of losing many competent 
engineers or being creative. SDD’s man¬ 
agement took the creative route: they put 
the Ethernet to work, attaching the devel¬ 
opment machines at both sites to a net¬ 
work, connecting the two sites with a 56- 
kilobit-per-second leased line, encourag¬ 
ing heavy use of electronic mail for work- 
related communication, and developing 
tools for facilitating distributed, multi¬ 
party development. 

As might be expected from Star’s ori¬ 
gins, most of the design and prototyping 
work was done in Palo Alto, whereas most 
of the implementation was done in El 
Segundo. Though this split was handled 
creatively, some of Star’s designers now 
believe it caused problems not overcome 
by extensive use of e-mail. For example, 
the implementors did not benefit from 
much of the prototyping done at PARC. 

The development process has been re¬ 
counted in detail elsewhere 6 and will not be 
repeated here. Suffice it to say that the Star 
development effort 

• involved developing new network 
protocols and data-encoding schemes 
when those used in PARC’s research 
environment proved inadequate; 

• involved a great deal of prototyping 
and user testing; 

• included a late redesign of the proces¬ 
sor; 

• included several software redesigns, 
rewrites, and late additions, some 
based on results from user testing, 
some based on marketing considera¬ 
tions, and some based on systems con¬ 
siderations (see below); 

• included a level of attention to the re¬ 
quirements of international custom¬ 
ers unmatched in the industry; and 

• left much of what was in the Star Func¬ 
tional Specification unimplemented. 

Tajo/XDE. Since the machine upon 
which Star ran was developed in parallel 
with the software, it was not available 
early-on for use as a software development 
platform. Early prototyping and develop¬ 
ment was done on Altos and successor re¬ 
search machines developed at PARC. 
Though the Mesa language ran on these 


machines, development aids for Mesa 
programmers were lacking. 

When the 8000 Series workstation be¬ 
came available, the systems group within 
SDD began working on a suitable develop¬ 
ment environment. Known internally as 
Tajo and externally as Xerox Develop¬ 
ment Environment (XDE), the completed 
development environment and the numer¬ 
ous tools written to run in it were quickly 
adopted by programmers throughout 
SDD. Star’s later improvements adopted 
many good ideas from Tajo. 

ViewPoint. Though Star’s introduc¬ 
tion at NCC ’81 was lauded in the industry 
press, initial sales were not what had been 
hoped. Almost immediately, efforts were 
launched to improve its performance, ex¬ 
tensibility, maintainability, and cost. 

ViewPoint software. Even before Star 
was released, the implementors realized 
that it had serious problems from their 
point of view. Its high degree of integra¬ 
tion and user-interface consistency had 
been achieved by making it monolithic: 
the system “knew” about all applica¬ 
tions, and all parts of the system “knew” 
about all other parts. It was difficult to cor¬ 
rect problems, add new features, and in¬ 
crease performance. The monolithic 
architecture also did not lend itself to dis¬ 
tributed, multiparty development. 

This created pressure to rewrite Star. 
Bob Ayers, who had been heavily involved 
in the development of Star, rewrote the 
infrastructure of the system according to 
the more flexible Tajo model. He built, on 
top of the operating system and low-level 
window manager, a “toolkit” for building 
Star-like applications. 

In the new infrastructure, transfer of 
data between different applications was 
handled through strict protocols involv¬ 
ing the user’s selection, thus making appli¬ 
cations independent from one another. 
The object-oriented user interface, which 
requires that the system associate applica¬ 
tions with data files, was preserved by 
having applications register themselves 
with the system when started, telling it 
which type of data file they correspond to 
and registering procedures for handling 
keyboard and mouse events and generic 
commands. User-interface consistency 
was fostered by building many of the stan¬ 
dards into the application toolkit. The de¬ 
velopment organization completed the 
toolkit and then ported or rewrote the exist¬ 
ing applications and utilities to run on top 
of it. 
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Other software changes included 

• the addition of several applications 
and utilities, including a Free-Hand 
Drawing program and an IBM PC 
emulation application; 

• optional window tiling constraints, so 
that users can have overlapping win¬ 
dows if desired; 

• redesigned screen graphics (icons, 
windows, property sheets, command 
buttons, and menus) to accommodate 
a smaller screen and to meet the de¬ 
mands of a more sophisticated public; 
and 

• improved performance. 

To underscore the fact that the new sys¬ 
tem was a substantial improvement over 
the old, the name was changed from Star to 
ViewPoint. ViewPoint 1.0 was released in 
1985. 

ViewPoint hardware. In addition to re¬ 
vising the software, Xerox brought the 
hardware up to date by designing a com¬ 
pletely new vehicle for ViewPoint: the 
6085 workstation. The new machine was 
designed to take advantage of advances in 
integrated circuitry, reductions in mem¬ 
ory costs, new disk technologies, and new 
standards in keyboard design, as well as to 
provide IBM PC compatibility. The 6085 
workstation has a Mesa processor plus an 
optional IBM-PC-compatible processor, 
one megabyte of real memory (expand¬ 
able to 4 megabytes), a hard disk (10 to 80 
megabytes), a choice of a 15- or a 19-inch 
display, an optical mouse, a new key¬ 
board, a 514-inch floppy disk drive, and, of 
course, an Ethernet connection. The base 
cost was initially $6,340 with the View- 
Point software. Like the 8010, the 6085 is 
sold as a vehicle for Interlisp and Smalltalk 
as well as for ViewPoint. 

Recent ViewPoint changes. The re¬ 
cently released ViewPoint 2.0 adds many 
features relevant to desktop publishing. 
These include 

• Xerox Prolllustrator, a new vector 
graphics editing application designed 
mainly for professional illustrators; 

• Shared Books, support for groups of 
users working on multipart docu¬ 
ments; 

• a Redlining feature, for tracking dele¬ 
tions and insertions in documents; 

• cursor keys, for moving the insertion 
point during keyboard-intensive 
work; and 


• stylesheets, for facilitating control of 
document appearance. 

Lessons from 
experience 

So what have we learned from all this? 
We believe, the following: 

Pay attention to industry trends. 

Partly out of excitement over what they 
were doing, PARC researchers and Star’s 
designers didn’t pay enough attention to 
the “other” personal computer revolu¬ 
tion occurring outside of Xerox. By the 
late seventies, Xerox had its own powerful 
technical tradition (mouse-driven, net¬ 
worked workstations with large bitmap¬ 
ped screens and multiple, simultaneous 
applications), blinding Star’s designers to 
the need to approach the market with 
cheap, stand-alone PCs. The result was a 
product that was highly unfamiliar to its 
intended customers: businesses. Nowa¬ 
days, of course, such systems are no longer 
unusual. 

Developing Star and ViewPoint in¬ 
volved developing several enabling tech¬ 
nologies, for networking, communicat¬ 
ing with servers, describing pages to laser 
printers, and developing software. At the 
time they were developed, these technolo¬ 
gies were unique in the industry. Xerox 
elected to keep them proprietary for fear of 
losing its competitive advantage. With 
hindsight, we can say that it might have 
been better to release these technologies 
into the public domain or to market them 
early, so that they might have become in¬ 
dustry standards. Instead, alternative ap¬ 
proaches developed at other companies 
have become the industry standards. 
Xerox’s current participation in the devel¬ 
opment of various industry standards indi¬ 
cates its desire to reverse this trend. 

Pay attention to what customers 
want. The personal computer revolution 
has shown the futility of trying to antici¬ 
pate all of the applications that customers 
will want. Star should have been designed 
from the start to be open and extensible by 
users, as the Alto was. In hindsight, exten¬ 
sibility was one of the keys to the Alto’s 
popularity. The problem wasn’t that Star 
lacked functionality, it was that it didn’t 
have the functionality customers wanted. 
An example is the initial lack of a spread¬ 
sheet application. The designers failed to 
appreciate the significance of this applica¬ 
tion, which may have been more important 


even than word-processing in expanding 
the personal computer revolution beyond 
engineers and hobbyists into business. 
Eventually realizing that Star’s closed¬ 
ness was a problem. Xerox replaced it with 
ViewPoint, a more “open” system that 
allows users to pick and choose applica¬ 
tions that they need, including a spread¬ 
sheet and IBM PC software. Apple Com¬ 
puter learned the same lesson with its Lisa 
computer and similarly replaced it with a 
cheaper one having a more open software 
architecture: the Macintosh. 

Know your competition. Star’s initial 
per-workstation price was near that of 
time-shared minicomputers, dedicated 
word-processors, and other shared com¬ 
puting facilities. Star was, however, com¬ 
peting for desktop space with microcom¬ 
puter-based PCs. ViewPoint has cor¬ 
rected that problem: The 6085 costs about 
the same as its competition. 

Establish firm performance goals. 

Star’s designers should have established 
performance goals, documented them in 
the functional specifications, and stuck to 
them as they developed Star. Where per¬ 
formance goals couldn’t be met, the corre¬ 
sponding functionality should have been 

In lieu of speed, the designers should 
have made the user interface more respon¬ 
sive. Designing systems to handle user 
input more intelligently can make them 
more responsive without necessarily 
making them execute functions faster. 
They can operate asynchronously with 
respect to user input, making use of back¬ 
ground processes, keeping up with impor¬ 
tant user actions, delaying unimportant 
tasks (such as refreshing irrelevant areas 
of the screen) until time permits, and skip¬ 
ping tasks called for by early user actions 
but rendered moot by later ones. View- 
Point now makes use of background proc¬ 
esses to increase its responsiveness. 

Avoid geographically split develop¬ 
ment organizations. Having a develop¬ 
ment organization split between Palo Alto 
and El Segundo was probably a mistake, 
less for reasons of distance per se than for 
lack of shared background in “PARC- 
style” computing. However, the adverse 
effect of sheer distance on communication 
was certainly a factor. 

Don’t be dogmatic about the Desktop 
metaphor and direct manipulation. Di¬ 
rect manipulation and the Desktop meta- 
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phor aren’t the best way to do everything. 
Remembering and typing is sometimes 
better than seeing and pointing. For ex¬ 
ample, if users want to open a file that is one 
of several hundred in a directory (folder), 
the system should let users type its name 
rather than forcing them to scroll through 
the directory trying to spot it so they can 
select it. 

Many aspects of Star were correct. 
Though certain aspects of Star perhaps 
should have been done differently, most of 
the aspects of Star’s design described at 
the beginning of this article have with¬ 
stood the test of time. These include 

• Iconic, direct-manipulation, object- 
oriented user interface. The days of cryp¬ 
tic command languages and scores of 
commands for users to remember (a la 
Unix and MS-DOS) should have passed 
long ago. 

• Generic commands and consistency 
in general. Even Macintosh could use 
some lessons in this regard: the Duplicate 
command copies files within a disk, but 
users must drag icons to copy them across 
disks and must use Copy-Paste to copy 
anything else. 

• Pointing device. Although cursor 
keys have some advantages and certainly 
would have enhanced Star’s market ap¬ 
peal (as they have Viewpoint’s), Star’s 
designers stand by the system’s primary 
reliance on the mouse. This does not imply 
a commitment to the mouse per se, but 
rather to any pointing device that allows 
quick pointing and selection. As inter¬ 
faces evolve in the future, high-resolution 
touch screens and other more exotic de¬ 
vices may replace mice as the pointing 
devices of choice. 

• High-resolution display. Memory is 
now cheap, so the justification for charac¬ 
ter displays is gone. 

• Good graphic design. Screen graphics 
designed by computer programmers will 
not satisfy customers. The Star designers 
recognized their limitations in this regard 
and hired the right people for the job. As 
color displays gain market presence, the 
participation of graphic designers will 
become even more crucial. 

• 16-bit character set. An eight-bit char¬ 
acter set (such as ASCII) cannot accom¬ 
modate international languages ade¬ 
quately. Star and Viewpoint’s use of a 
16-bit character set and of special typing 
and rendering algorithms for foreign lan¬ 
guages is the correct approach. 

• Distributed, personal computing. 


Though the reorientation of the industry 
away from batch and time-shared comput¬ 
ing toward personal computing had noth¬ 
ing to do with Xerox, PARC, or Star, it was 
an important part of the computing phi¬ 
losophy that led to Star. 


S tar has had an indisputable influ¬ 
ence on the design of computer sys¬ 
tems. For example, the Lisa and 
Macintosh might have been very different 
had Apple’s designers not borrowed ideas 
from Star, as the following excerpt of a 
Byte magazine interview of Lisa’s design¬ 
ers shows: 

Byte: Do you have a Xerox Star here that you 
work with? 

Tesler: No, we didn’t have one here. We went 
to the NCC [National Computer Conference] 
when the Star was announced and looked at it. 
And in fact it did have an immediate impact. 
A few months after looking at it we made some 
changes to our user interface based on ideas 
that we got from it. For example, the desktop 
manager we had before was completely dif¬ 
ferent; it didn’t use icons at all, and we never 
liked it very much. We decided to change ours 
to the icon base. That was probably the only 
thing we got from Star, I think. Most of our 
Xerox inspiration was Smalltalk rather than 
Star. 7 

Elements of the Desktop metaphor ap¬ 
proach also appear in many other systems. 

The history presented here has shown, 
however, that Star’s designers did not in¬ 
vent the system from nothingness. Just as 
it has influenced systems that came after it, 
Star was influenced by ideas and systems 
that came before it. It is difficult to inhibit 
the spread of good ideas once they are ap¬ 
parent to all, especially in this industry. 
Star was thus just one step in an evolution¬ 
ary process that will continue both at 
Xerox and elsewhere. That is how it should 
be. □ 
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You could spend and spend 
trying to hire good Ada programmers 
and still not find what you need. Big 
demand; short supply. The irony 
is, your best Ada people may be the 
programmers you already have; all 
they need is good training. 

Alsys offers a full range of quality 
Ada training products for growing your 
own programmers. For example... 

■ A 27 video tape seminar covering 
the entire Ada language-18 hours 
of authoritative instruction by the 
principal designer of the language 
itself. Benefit? Understanding Ada’s 
architecture and scope should be 

the foundation for all further work or 
study. It will help develop that most 
elusive skill: the Ada programming 
intuition to guess right. 

■ For programmers ready for 
hands-on skills development, a 
comprehensive CAI course on a PC, 
running 50-60 hours, with exer¬ 
cises and progress tracking. Multiple 


users. Licenses for 5 machines. The 
course is also excellent for brushing 
up, or extra work on one subject, or 
for new employees. 

■ For practicing, and then moving 
directly to serious Ada programming, 
Alsys offers a full-featured, production 
quality Ada compiler, with tools, 
for the PC AT. This same compiler is 
used to build some of the largest Ada 


Good Ada training for your own 
people. For Ada now. Write or call. 
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Ada Programmers 
Are Made - Not Hired. 


programs in 
existence! 

Alsys offers 
more training 
products. A 
CAI course for 
programmers 
familiar with 
Fortran... 
a searchable, 
on-line version 
of the Reference 
Manual... 
a (limited) 
offering of live 
training courses. 


In the US: Alsys, Inc., One Burlington Business Center, 67 So. Bedford St.. Burlington, MA01803-5152 
Tel: 617-270-0030, FAX: 617-270-6882 

In the UK: Alsys Ltd., Partridge House. Newtown Rd.. Henley-on-Thames, Oxon RG91EN Tel: 44 (491) 579090 
In the rest of the world: Alsys SA.29 Avenue de Versailles,78170 La Celle, St.Cloud, France Tel:33(l)3918.l2.44 
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. _ Ichbiah, Barnes & Firth on Ada 2 7-tape Video Series. 
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| _ PC AT Compiler and Tools. _ AdaQuery On-Line Reference. 
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distributed control and control migration. Research 
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Systems 
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Customization without f rustration.Worldwide. 



Honeywell-Bull. Waltham MA 
Honeywell-Bull used Design/OA to 
create a graphical micro-computer 
interface to monitor their nightly 
mainframe batch processing. The 
application retrieves batch process¬ 
ing data, initiates the batch jobs, 
and provides the operator real¬ 
time processing status throughout 
the night. 


PRC. McLean VA 
Planning Research Corporation 
used Design/OA to develop an Ada 
diagramming tool by adding Ada 
specific graphics to Design/2.0. 
This new tool, called AdaDesign, 
is used by Ada programmers for 
flow charting and system design. 


MIT. Cambridge, MA 
"With Design/OA we can go from 
an idea to an implementation very 
quickly. It has expanded the range 
of questions we can explore, given 
the same resources? 

Alexander Levis, Senior Research 
Scientist, Laboratory for Informa¬ 
tion and Decision Systems. 


AT&T Bell Labs. Middletown NJ 
AT&T Information Systems used 
Design/OA to build a reverse engi¬ 
neering application that provides 
dynamic documentation of large 
mainframe C programs. Program¬ 
mers can graphically view the pro¬ 
gram's functions, files, variables, 
and their relationships. 
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tions in a fraction of the time it would take with any other method. 
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level programming interface to its C library routines and data struc¬ 
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prototype in weeks and a finished application in months, not years. 

Cross-Platform Applications 
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for MS-DOS®/MS-Windows,™ UNIX™/X Window System,™ Apple 
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Vector Pipelining, 
Chaining, and Speed on the 
IBM 3090 and Cray X-MP 


Hui Cheng, University of Illinois at Chicago 


C omputer architecture has experi¬ 
enced a natural evolution, from 
serial processors to highly pipe¬ 
lined vector processors or multiple pipe¬ 
lined vector processors like the IBM 3090/ 
VF and the Cray X-MP. 

The literature reports many benchmark 
techniques for evaluating the performance 
of vector processors. However, most of the 
evaluation techniques do not consider the 
details of vector processing. Jordan re¬ 
ported the benchmark comparison of dif¬ 
ferent machines by running a collection of 
research codes.' Dongarra developed a 
well-known standard benchmark tech¬ 
nique by solving a system of linear equa¬ 
tions with the Linpack routines written in 
Fortran to evaluate the vector performance 
of vector processors. 2 Timings have been 
reported for a large number of machines, 
ranging from personal computers to super¬ 
computers. 

McMahon reported a benchmark tech¬ 
nique that uses a set of Fortran kernels 
called the Livermore Loops, which consist 
of 24 code fragments extracted from prac¬ 
tical research codes. 3 In this benchmark 
test, all fragments were timed separately at 
three different vector lengths. The results 
of these benchmark tests will likely dem¬ 
onstrate the potential performance of real 
applications, but give little information to 
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Evaluating 
vectorization on the 
IBM 3090 and Cray 
X-MP yields concepts 
applicable to other 
vector processors. 
Methods suggested 
here can speed up 
vector performance. 


users about how to improve the perfor¬ 
mance of a program by taking advantage of 
the computational power of a particular 
vector processor. 

However, a user is usually more inter¬ 
ested in how to make the best use of the 
machine he or she has, rather than in which 
machine is best. A serious shortcoming of 
all the aforementioned benchmark tech¬ 
niques is that the analysis of the concurrent 
vector processing capabilities of a vector 
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processor from the results of these bench¬ 
marks is almost impossible. 

Lindsay reported an improved bench¬ 
mark technique that consisted of eight 
vector instructions. 4 By measuring the 
CPU time separately for these kernels at 
vector lengths from 1 to 200,000 in both 
vector and scalar modes along with loop 
unrolling, we can obtain useful informa¬ 
tion for machine users and designers about 
the vector processor being tested. 

However, the ability to test the perfor¬ 
mance of the concurrent vector operations 
of vector processors using this benchmark 
is limited. For example, the vector chain¬ 
ing of the divide operation on the Cray X- 
MP cannot be tested by the Lindsay 
method. 4 

Speedup is defined as the ratio of the 
CPU time for a given code between scalar 
and vector modes. As shown in this article, 
the speedup of the vector operation X(f) = 
R * Y(f) + R * Z(I), which invokes the 
compound vector instruction on the IBM 
3090, is about twice as much as the speedup 
of the equivalent vector operation X(I) = 
(T(/) + Z(/)) * R, which doesn’t use the 
compound operation. Therefore, it be¬ 
comes necessary to analyze the concurrent 
vector processing performance of vector 
processors to fully utilize the capabilities 
of vector processors and indicate potential 
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Figure 1. The vector chaining on the X-MP for X(I) = Y(I) + R * Z(I). The scalar 
register S R contains the value R, while the vector registers V x , V y , V z , and V con¬ 
tain vectors X(I), Y(I), Z(I), and R * Z(/), respectively. The pipelined result R * 
Z(I) from the multiply functional unit is stored into the vector register V and de¬ 
livered at the same time to the add functional unit for a pipeline operand. 


improvements for future computers. Based 
on McMahon and Lindsay’s methods, a set 
of Fortran kernels for evaluating the per¬ 
formance of the concurrent vector 
operations of vector processors is devel¬ 
oped in this article that can be used to test 
the following characteristics of a vector 
processor: 

• Vector performance versus scalar per¬ 
formance. 

• Concurrent processing of load, store, 
add, multiply, and divide vector 
operations. 

• The effect of cache memory on the 
concurrent vector operations and 
speed. 

• The vector break-even lengths. 

• The speed hierarchy of vector arithme¬ 
tic operations. 

• The scalar expansion break-even 
lengths. 

In this article, I will clarify vector pipe¬ 
lining and chaining through the use of 
timing and pipeline diagrams of the in¬ 
struction execution process. Next, I will 
illustrate the technique for evaluating the 
performance of the concurrent vector 
operations of vector processors by testing 
two of the most widely used computers 
with vector facilities: the IBM 3090 and 
Cray X-MP. Then, based on the testing 
results analyzed at the assembler level, I 
give suggestions for machine users and 
designers about vectorization on these two 
machines. Use of the ideas I present here is 
not limited to these two machines; the 
ideas can also be applied to other vector 
processors. The actual implementations, 
however, may differ depending on individ¬ 
ual machine architecture. 


Vector pipelining and 
chaining 

The instruction pipeline in vector pro¬ 
cessors allows more than one instruction to 
execute at different stages at the same 
time. Instruction pipelining is achieved by 
dividing the execution of each instruction 
into a number of phases, such as fetch, 
decode, operand fetch, and instruction 
execution. 

Instead of fetching scalars from memory 
and performing arithmetic on them, the 
data pipeline allows vectors to be streamed 
from the memory into the CPU, where they 
are manipulated by pipelined functional 
units. In pipelined functional units, the 
stages of instruction execution are over¬ 
lapped to reduce execution time for a given 
operation. 

For example, the floating-point-multi- 
ply functional unit can be segmented into 
several stages on a vector processor. For 
the execution of a floating-point multipli¬ 
cation, the individual operand pairs flow 
through the pipeline and advance a stage 
on every cycle. A new pair of operands is 
sent into the pipeline every cycle. 

Therefore, after a start-up delay corre¬ 
sponding to the time it takes to fill the 
pipeline, one result per cycle can be pro¬ 
duced. The pipelined vector processors 
that eliminate instruction start-up time for 
all but the first operand can dramatically 
increase computation speeds. 

However, vectorized programs may also 
run slower than equivalent scalar pro¬ 
grams, especially for short vectors where 
the start-up delay of vector pipelines be¬ 
comes significant. For example, the IBM 


3090/120E (hereafter referred to as the 
3090) takes 30 cycles to start up pipelines. 
Therefore, information about the vector 
break-even length (the minimum vector 
length for the vector mode of a vector 
processor surpassing the equivalent scalar 
mode) is very important for users of these 
machines. 

Access time (the time required to fetch 
an operand from the memory to an operat¬ 
ing register or a functional unit) depends 
on individual machine architecture. For 
example, the 3090 has a 64-kilobyte fast 
cache memory, which is used to hold a 
portion of the data and instructions most 
recently referenced. 

The time for data transfer among func¬ 
tional units, registers, and cache is one 
cycle per double word (8 bytes). The cache 
is addressed by means of 128 cache classes 
and four cache sets; a cache has a total of 
512 cache lines, each with 128 bytes. 

A cache line is transferred to the cache if 
the processor requests that line or is trans¬ 
ferred to the central memory if the cache 
location is requested for a different line. 
Vector performance may degrade if the 
data referenced by vector instructions is 
not in cache; this precipitates the bottle¬ 
neck for computers with cache memory. 

Unlike the 3090 with cache memory, the 
Cray X-MP/48 (hereafter referred to as the 
X-MP) transfers data between the central 
memory and registers directly without 
cache. 

For example, the central memory of the 
X-MP used in the tests is divided into 64 
interleaved memory banks that may 
operate concurrently. Access times are 14 
cycles for scalar and 17 cycles plus vector 
length for a vector, respectively. The cen¬ 
tral memory can be accessed through three 
ports — A, B, and C — as well as through 
I/O. Each port can be used concurrently. 

In contrast to cache degradation, mem¬ 
ory contention, which arises when more 
than one port requests a bank concurrently 
in a reference cycle, may be a major bottle¬ 
neck to the machines without cache. For 
example, if a memory bank busy conflict 
occurs, an extra four cycles will be needed 
to access the memory on the X-MP. 

Expanding scalars to vectors may gain 
speedup on a machine without cache 
memory. Then, like the vector break-even 
length, the scalar expansion break-even 
length (the maximum vector length for 
gaining speedup by expanding scalars to 
vectors) is also vital information for ma¬ 
chine users. 

Vector chaining is another technique for 
increasing the speed of the vector proces- 
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Figure 2. The X diagram for X(/) = Y(I) + R* Z(7) on the 3090 in scalar mode. The ordinate is the computer operations cor¬ 
responding to different machine cycles. (Requires 11 cycles for one element of X(I ) and 1UV cycles for a loop.) 


sor and reducing the vector break-even 
length. If the pipelined result of the first 
functional unit is immediately delivered as 
the pipelined operand into the subsequent 
functional unit and concurrently stored 
into the destination vector register, a vec¬ 
tor chaining operation is created that can 
be demonstrated by the following Fortran 
linked triad, where N is the vector length: 

Do 100/= 1,1V (S101) 

100 X(7) = K(7) + R * Z(I) (SI02) 

Figure 1 illustrates the chaining 
operation on the X-MP for the above vec¬ 
tor operations: details will be discussed 
later. 

Full chaining occurs if the instruction 
for chaining is issued before or at the time 
the first element of the result pipeline ar¬ 
rives at the destination vector register. 
Partial chaining occurs if the instruction is 
issued after the arrival of the first element 
of the result pipeline. Therefore, the 
amount of concurrency in a chained vector 
operation depends on the chaining modes. 

The clock time for issuing the instruc¬ 
tion-causing chaining as soon as the first 
result arrives for use as an operand is called 
the chain slot time. The X-MP is only 
capable of partial chaining. With chaining 
capabilities, a vector processor can chain 
two or more vector instructions, and two or 


more results can be produced per clock 
cycle. 

Chaining is one of the major factors 
affecting the speed of vector processors. 
Chained operations are actually over¬ 
lapped vector operations. Unlike vector 
pipelines, which are almost identical in all 
different vector processors, chaining 
operations mainly hinge on individual 
machine organization. 

Since the multiply pipeline is essentially 
independent of the add pipeline, it is pos¬ 
sible to use both multiply and add func¬ 
tional units simultaneously. For example, 
on the 3090, Fortran code using REAL*8 
data can access a compound vector instruc¬ 
tion VMAD that allows both a multiply 
and an add to proceed concurrently after 
start-up. In addition, the block data trans¬ 
fer between the expanded and central stor¬ 
age can be performed synchronously with 
other operations. 5 

Unlike the 3090, the X-MP CPU auto¬ 
matically detects the opportunity to chain 
operations, and chained operations are not 
explicitly specified by the assembly in¬ 
structions. 6 

However, the chained operation can be 
detected according to certain rules. 

Each vector (V) register has two reser¬ 
vations that describe the condition of a V 
register in use. One reserves it as an oper¬ 
and register, and another reserves it as a 
result register. 


If a V register is reserved as a result, it 
can be used at any time as an operand and 
a resultant chaining occurs. If a V register 
is reserved as an operand, it cannot be used 
as a result or operand register until the 
operand reservation is cleared; that is, no 
chaining occurs. But, if different func¬ 
tional units and all different V registers are 
accessed, vector operations can be pro¬ 
cessed concurrently in the CPU. 

The X-MP is capable of chaining two 
loads, one store, one add, one multiply, one 
reciprocal approximation, and many other 
operations, such as address calculations. 6 
For cross comparison, the terminology of 
the vector chaining hereafter refers to the 
procedure that can process the different 
vector operations concurrently. Thereby, 
loosely speaking, the 3090 is capable of 
chaining one multiply and one add. 

Vector pipelining and chaining can be 
clarified by considering the performance 
of the Fortran-linked triad S101 -102 from 
the assembler point of view. For illustra¬ 
tive purposes, the assembler instructions 
of the loop setup statement S101 are ig¬ 
nored, and only the essential instructions 
are discussed. 

Using an X diagram. Figure 2 shows the 
execution process for S102 on the 3090 in 
scalar mode, where the Xs represent real 
machine cycles consumed by the associ¬ 
ated instructions. 

There are five instructions for executing 
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x Store X(N) 

X Store X(N—1) 


x Store X(3) 

x Store X(2) 

x Store X(1) 

xxx Add X(N)»Y(N)+(R*Z(N)) 

xxx Add X(N-1)«Y(N-1)+(R*Z(N-1)) 



xxx Add X(3)*Y(3)+(R*Z(3)) 

xxx Add X(2)-Y(2)+(R*Z(2)) 

x x. Add X(1)-Y(1)+(R*Z(1)) 

Multiply R*Z(N) 

Multiply R*Z(N—1) 


x x 
xxx 

X X X X 
X X X X X 


X X X X X 


xxx Multiply R*Z(5) 

x x Multiply R*Z(4) 

x Multiply R*Z(3) 

Multiply R*Z(2) 
Multiply R»Z(l) 


2 3 4 3# 


N 


N+4 


2N+6 3N+6 


cycles 


Figure 3. The X diagram from X(I) = Y(I) + R* Z(I) on the 3090 in vector mode. (Requires (3N + 6) cycles plus start-up de¬ 
lay.) 


S102 in scalar mode on the 3090: 

• Load (LDR) scalar R from the cache 
memory into a scalar register (one cycle). 

• Multiply (MD) R in the scalar register 
by the element of Z(/) from the cache 
memory and put the product in the scalar 
register by the floating-point multiply 
functional unit that takes five cycles. 

• Add (AD) the element of R * Z(I) in the 
register and the element of Y(I) from the 
memory using the floating-point add func¬ 
tional unit that takes three cycles. 

• Store (STD) the result element of X(I) 
into the memory (one cycle). 

• Loop branch (BXLE) (one cycle). 

Each instruction is executed sequen¬ 
tially in scalar mode so that one result is 
produced every 11 cycles, as shown in the 
instruction execution timeline of Figure 2. 
Therefore, the 3090 takes 1 IN cycles to 
execute the loop S101 -102 with the vector 
length of N in scalar mode. 

Figure 3 shows the X diagram of the 
instruction execution timeline for S102 on 


the 3090 in vector mode. For cross com¬ 
parison, the cycles of the operations are 
assumed the same in both scalar and vector 
modes, which is true for most operations. 

At the clock cycle 1, the scalar R in the 
scalar register and the first element Z( 1) of 
vector Z(/) from the cache memory is trans¬ 
mitted to the floating-point multiply func¬ 
tional unit. 

The first result R * Z(l) exits from the 
functional unit at clock cycle 5 and is 
delivered to a vector register. Because of 
the full segmentation of the functional unit, 
the second pair of elements R and Z(2) is 
sent to the multiply functional unit at cycle 
2. At clock cycle 2, the multiplications of 
R * Z( 1) and R*Z(2) are processed concur¬ 
rently by the multiply functional unit since 
the multiplication of R * Z(l) is started at 
the previous clock cycle. 

The second result R * Z(2) emerges at 
clock cycle 6 and is delivered to the second 
element of the result vector register for the 
vector of R * Z(I). Continuing in this 
manner, a new pair of operands is sent into 


the multiply functional unit every cycle, 
and the corresponding product is obtained 
five cycles later and put into the result 
vector register. 

Since a new multiplication is started on 
every cycle, five multiplications can be 
processed simultaneously. In general, the 
number of concurrently processed 
operations in a functional unit is equal to 
the functional unit time, which is five 
cycles for the multiply on the 3090. 

After (N + 4) cycles for processing the 
vector multiplication of R * Z(/), the pipe¬ 
lined addition of the vector Y(I) from the 
cache memory and R * Z(/) in the vector 
register is performed by the floating-point 
add functional unit with the unit time three 
cycles, which takes (N + 2) cycles, in the 
same manner as by the pipelined multiply 
functional unit. 

Finally, the result of X(I) in a vector 
register is stored through a storing pipeline 
into the memory, which takes N cycles. In 
vector mode, all individual vector opera¬ 
tions (multiply VMD, add VAD, and store 
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Store X(3)-Y(3)4-R»Z(3) 
St ore X(2)-Y(2)+R«2(2) 


Store X(1)«Y(1)+-R*Z(1)' 

3 

• ■ • 

X 

i • ’ 

Add X(3)-Y(3)+(R*Z(3)) 
Add X(2)-Y(2)+(R.Z(2)) 

Add X(1)-Y(1W**Z(I)) 

: 

X X X X 3 

X X X X X J 

< X X X X X 

X 


Multiply R*Z(3) 

Multiply R*Z(2) 

Multiply R»Z(1) > 

X X X X X X 

X X X X X x > 

j • ’ 



XXXXXXXXXXXXXXX) 

XXXXXXXXXXXX XXXV} 

xxxxxxxxxxxxxxxxx 

t X 

f 


Load Y(3) 

Load Y(2) 
load Y(1) 


xxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxxx I 
th« 1—14 cycles for loading R 


Load Z(3) 

Load Z(2) 

Lood Z(1) 

cycles 


Figure 4. The X diagram for X(I) = Y(I) + R*Z(I) on the X-MP in vector mode. The concurrent processing of loads, store, 
add, and multiply begins at clock cycle 45. (Requires (N + 60) cycles plus start-up delay.) 


VSTD) are pipelined to eliminate the 
branch instruction in scalar mode. 

Therefore, due to vector pipelining, the 
processing time for S102 is reduced from 
1 IN cycles in scalar mode to (3 N + 6) 
cycles plus start-up delay. Note that the 
dominant machine cycle 3 N in vector mode 
for long vectors is independent of the 
number of cycles required for individual 
operations, as shown in Figure 3. 

Because the vector register of a vector 


processor cannot contain vectors longer 
than the length of the vector register, if the 
vector length N is longer than the length of 
the vector registers, the vector is split into 
128-element segments or less on the 3090 
and 64-element segments or less on the X- 
MP and processed segment by segment. 

The vector pipelining is similar on both 
the 3090 and X-MP, except that the cycles 
for the individual operations differ. For 
example, the floating-point add, multiply, 


load, and store take 6,7,17, and 17 cycles 
on the X-MP 6 instead of 3, 5, 1, and 1 
cycles on the 3090. 7 

Figure 4 shows the X diagram of the 
instruction execution timeline for S102 on 
the X-MP. After 14 cycles delay for load¬ 
ing the scalar R from the memory into a 
scalar register (not drawn in Figure 4), the 
first two elements, T(l) and Z(l) of two 
vectors Y(I) and Z(/), begin to load from 
the interleaved memory into two vector 
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Figure 5. The pipeline diagram for X (/) = 7(/) +R* Z(I) on the X-MP in vector 
mode, where the start-up and end details are ignored. 


registers at clock cycle 15 through ports A 
and B. 

For clarity, the loading of the elements 
7(1) and Z(l) in Figure 4 start simultane¬ 
ously. However, the actual execution of 
these two vector loads may begin a few 
cycles apart. The vector loadings are pipe¬ 
lined such that two elements, each from 
different vectors, are loaded into the two 
different vector registers after 17 cycles 
delay. The first multiply R * Z(1) is started 
the moment (at the clock cycle 32) the 
element Z( 1) is loaded without waiting for 
the rest of the loads to complete. After 
seven cycles delay for multiply, the result 
of the product R * Z( 1) is used as an 
operand for addition of 7(1) + R * Z( 1) 
since the element 7(1) was preloaded si¬ 
multaneously with the element Z(l) and 
put into a vector register concurrently at 
the clock cycle 39. This is called vector 
chaining, as shown in Figure 1. 

Due to vector pipelining and chaining, 
the concurrent processing of addition 7( 1) 
+ R * Z( 1) and multiplication of R* Z(l) is 
started at clock cycle 39 by the add and 
multiply functional units, respectively. 
The first result X(l) is produced by the add 
functional unit at clock cycle 45 and begins 
to store into the memory through port C. 


After 60 cycles for initiation, the first 
element X(l) of the result vector X(I) ar¬ 
rives at the memory and one element per 
cycle arrives thereafter. Totally, (N + 60) 
cycles plus start-up time are required for 
SI02, as shown in Figure 4. Due to the 
vector chaining, the dominant machine 
cycles in vector mode are reduced from 3 N 
on the 3090 to IN on the X-MP. 

Although an X diagram such as Figure 4 
is detailed, it is not very easy to draw. For 
the chaining analysis point of view, this 
article introduces a simplified representa¬ 
tion of the instruction execution process 
called a pipeline diagram, without consid¬ 
ering the pipeline start-up and end details. 
A pipeline diagram consists of different 
pipelines, each representing different vec¬ 
tor instructions. 

The pipeline diagram for execution of 
S101 -102 corresponding to the X diagram 
of Figure 4 is drawn in Figure 5, where the 
dark solid line represents the multiply 
pipeline, the light solid line represents the 
add pipeline, the dotted lines represent 
load pipelines, and the dashed line stands 
for the vector store pipeline. 

As Figure 5 shows, it is obvious that two 
loads, one multiply, one add, and one store 
proceed concurrently, due to vector pipe¬ 


lining and chaining. Therefore, only one 
cycle is required to process one element of 
X(I) after start-up. 

Note that, due to vector chaining, the 
estimation of the computational complex¬ 
ity of a code solely by counting the number 
of the vector instructions may be mislead¬ 
ing. For example, five X-MP vector assem¬ 
bler instructions are required for S102, 
whereas the 3090 has only three, as shown 
in Figures 3 and 5, respectively. j 

Test setup 

To eliminate CPU time-measurement 
overhead from the timing routines and 
overcome the uncertainty of the measure¬ 
ment due to the shortness of vectors, the 
CPU time is measured as follows: 

Get CPU timel 
Get CPU time2 

Do 200 II = 1, NREP 
Execute vector operations 

200 Continue 
Get CPU time3 

where “vector operations” are the Fortran 
code such as S101-102. 

Different values are assigned to the 
elements of a vector before getting CPU 
time 1. Zeros are avoided since multiplying 
by zero is detected and treated as a trivial 
fast case on the 3090. 5 This is an advantage 
for calculations involving many zeros, 
such as sparse matrix calculations, but is 
not the concern of this article. The CPU 
time for vector operations is calculated by 

CPU time - time3-time2-(time2-time 1 ) 
NREP 

The number NREP is selected to make 
sure that the time difference between time3 
and time2 is about 20~30 seconds. Mea¬ 
sured this way between each run with the 
same setup, the CPU time appears quite 
stable. 

The test on the 3090 was carried out at 
the University of Illinois at Chicago. The 
CPU clock cycle of the machine is 18.5 
nanoseconds. An 3090 VS Fortran 2.2 
compiler was used with OPT(3) for scalar 
and VECTOR LEVEL(2) for vector. The 
data type is REAL*8 (8 bytes: 1 byte for 
exponent and 7 bytes for mantissa). The X- 
MP at the National Center for Supercom¬ 
puting Applications at Urbana-Champaign 
has a cycle time of 8.5 nanoseconds and 
four processors, but only a single proces¬ 
sor is used in this work. A CFT 1.14E 
Fortran compiler is used with data of 
REAL (8 bytes: 2 bytes for exponent and 6 


36 


COMPUTER 








Table 1. The near-maximum Mstmts and Mflops of the Fortran kernels in vector length #=1,024 on the IBM 3090 and 
#=2*10 5 on the Cray X-MP, respectively. 


No. 

Vector Operations 

N 

Mstmts 

IBM 

=1,024 

Mflops 

N= 

Mstmts 

CRAY 

1,024 N- 

Mflops Mstmts 

200,000 

Mflops 

SI 

X(/)=y(7) 

18.76 


47.28 


48.47 


S2 

X(l)=Y(f)+Z(f) 

12.99 

12.99 

44.66 

44.66 

46.17 

46.17 

S3 

X(i)=R+U(r> 

18.61 

18.61 

47.54 

47.54 

48.37 

48.37 

S4 

X([)=Y(I)*Z(!) 

12.80 

12.80 

44.52 

44.52 

46.97 

46.97 

S5 

X(J)=R*(J(l) 

18.42 

18.42 

47.78 

47.78 

49.19 

49.19 

S6 

X(T)=Y(l)/Z(T) 

2.66 

2.66 

23.30 

23.30 

24.06 

24.06 

S7 

X(I)=RIU(1) 

2.85 

2.85 

23.86 

23.86 

24.38 

24.38 

S8 

X(I)=Y(I)+Z([) *U(l) 

9.84 

19.68 

31.91 

63.82 

31.80 

63.60 

S9 

X(I)=Y(J)+R*Z(1) 

12.78 

25.56 

45.51 

91.02 

45.96 

91.92 

S10 

X(I)=R* Y(I)+R*Z(l) 

12.69 

38.07 

38.96 

116.88 

40.31 

120.93 

Sll 

X(I)=Rl*Y(D+R2*Z(I) 

12.61 

37.83 

38.88 

116.64 

40.18 

120.54 

S12 

X(I)=(Y(r)+Z([))*R 

10.06 

20.12 

44.20 

88.40 

46.33 

92.66 

S13 

X(I)=U(I)*Y([)+U(D*Z(D 

9.50 

28.50 

31.79 

95.37 

31.92 

95.76 

S14 

x([)=u\(i)*Y(i)+m(n*z(i) 

7.93 

23.79 

31.19 

93.57 

30.89 

92.67 

S15 

X(I)=(Y(f)+Z(I))*U(f) 

9.59 

19.18 

31.93 

63.86 

32.05 

64.10 

S16 

X(I)=Y(D*U(D/Z(I) 

2.45 

4.90 

19.64 

39.28 

19.69 

39.38 

S17 

x(r)=Y(D+u(f)/z(i) 

2.46 

4.92 

23.01 

46.02 

23.64 

47.28 

S18 

X(r)=Y(i)+R/Z(i) 

2.65 

5.30 

22.94 

45.88 

23.58 

47.16 

S19 

X(D=R/Y(r)+R/Z(i) 

1.43 

4.29 

14.13 

42.39 

14.26 

42.78 

S20 

X(I)=R 1 IY(I)+R2/Z(I) 

1.44 

4.32 

13.95 

41.85 

14.26 

42.78 

S21 

x(/)=R*(i/y(/)+i/z(/)) 

1.39 

5.56 

16.29 

65.16 

16.67 

66.68 

S22 

XV)=U(I)/Y(D+U(D/Z(D 

1.39 

4.17 

13.71 

41.13 

13.82 

41.46 

S23 

X(l)=um/Y(D+U2(D/Z([) 

1.32 

3.96 

13.77 

41.13 

13.81 

41.43 

S24 

X(n=U(I)*(\IY{[)+\IZ(D) 

1.37 

5.48 

16.49 

65.96 

16.65 

66.60 


bytes for mantissa). The routine TIMER 
and ITMUCPU is used to measure CPU 
time on the 3090 and X-MP, respectively. 
The test was mainly carried out in the 
general user environment. The stand-alone 
test was also made on the 3090. The testing 
results show that the CPU time for both 
single- and general-user environments is 
almost the same. 

The vector performance for long and 
short vectors is very different, depending 
on the individual machine organization. 

^ Therefore, to save CPU time and ensure 
clarity while not losing crucial informa¬ 
tion, the selected Fortran kernels are tested 
in three different vector lengths: short, 
intermediate, and long. 

Since the vector break-even lengths on 
the X-MP are much shorter than those on 
the 3090, as shown in this article, vector 
lengths 6 and 12 were chosen to test the 
performance of short vectors on these two 
machines. The length of the vector register 
was chosen as the intermediate vector 
length. 


A pretest run was made to choose the 
long vector length. The Mflops (million 
floating-point operations per second) al¬ 
most reached the maximum for vector 
length 1,024 on the 3090, and this is sup¬ 
ported by the results Lindsay reported. 8 
However, due to cache degradation, the 
Mflops will decrease for long vectors. For 
example, the Mflops for adding two vec¬ 
tors are 12.99, 12.21, 11.73, and 4.05 for 
vector length N equal to 1,024, 1,500, 
2,000, and 1 * 10 s , respectively. 

Since the main focus of this article is 
chaining analysis rather than testing cache 
degradation, vector length 1,024 was cho¬ 
sen to test the performance of long vectors 
on the 3090. The maximum Mflops on the 
X-MP is reached about the vector length 2 

* 10 s . For example, the Mflops of adding 
two vectors are 44.66, 45.43, 46.17, and 
45.66 for vector length N equal to 1,024,1 

* 10 5 , 2 * 10 5 , and 6 * 10 s (near memory 
limit), respectively. Table 1 gives the 
Mstmts (million statements per second) 
and Mflops at vector length 1,024 and 2 * 


10 5 . Note that the difference of the vector 
performance between vector length 1,024 
and 2 * 10 5 is not significant on the X-MP. 

For cross comparison with the 3090, the 
following performance analysis for long 
vectors on the X-MP is mainly based on the 
vector length 1,024, although the results 
are valid for longer vectors. Respectively, 
Table 2 and Table 3 give the CPU time of 
the Fortran kernels in both vector and sca¬ 
lar modes on the 3090 and X-MP at three 
different vector lengths N. Table 4 gives 
the corresponding speedup on both the 
3090 and the X-MP as well as the CPU 
ratio of the 3090 to the X-MP for vector 
length 1,024. 

Comparison of vector 
operations at the 
assembler level 

Since most engineering and scientific 
calculations consist of sequences of some 


September 1989 


37 






Table 2. The CPU time (in seconds) for the Fortran kernels in both vector and scalar modes with different vector lengths N 
on the IBM 3090. 


No. 

Vector Operations 

N= 

Vector 

(*10- 4 ) 

: 12 

Scalar 

(*10-") 

N= 

Vector 

(*KH) 

■ 128 

Scalar 

(♦lO -4 ) 

N= 

Vector 

(*10“ 3 ) 

:1,024 

Scalar 

(*10- 3 ) 

SI 

X(D=Y(D 

0.03649 

0.03495 

0.08151 

0.3401 

0.05457 

0.2729 

S2 

X(I)=Y(I)+Z(I) 

0.04592 

0.04815 

0.1127 

0.4853 

0.07886 

0.3918 

S3 

X(I)=R+U(I) 

0.03702 

0.04803 

0.08197 

0.4845 

0.05503 

0.3895 

S4 

X(J)=Y(I)*Z(I) 

0.04680 

0.05432 

0.1136 

0.5462 

0.08000 

0.4421 

S5 

X(I)=R*U(I) 

0.03782 

0.05342 

0.08276 

0.5420 

0.05560 

0.4362 

S6 

X(/)=K(/)/Z(/) 

0.08221 

0.1177 

0.4935 

1.219 

0.3843 

0.9994 

S7 

x([)=R/u(r) 

0.07321 

0.1159 

0.4620 

1.230 

0.3594 

1.007 

S8 

X(I)=Y(D+Z(I)*U(f) 

0.05526 

0.06866 

0.1489 

0.6878 

0.1041 

0.5555 

S9 

X(f)=Y(r)+R*Z(I) 

0.04689 

0.06660 

0.1191 

0.6786 

0.08015 

0.5494 

S10 

X(I)=R*Y(l)+R*Z(I) 

0.04819 

0.09396 

0.1214 

0.9693 

0.08069 

0.8085 

Sll 

X(f)=Rl*Y(I)+R2*Z(I) 

0.04820 

0.09692 

0.1215 

1.004 

0.08123 

0.7808 

S12 

X(D=(Y(I)+Z(I))*R 

0.05229 

0.06662 

0.1399 

0.6794 

0.1018 

0.5415 

S13 

X(I)=U(D*Y(I)+U(0*Z(J) 

0.05719 

0.09809 

0.1446 

0.9970 

0.1078 

0.8022 

S14 

X(D=U\ (I)*Y(f)+U2(f)*Z(I) 

0.06668 

0.09829 

0.1754 

1.004 

0.1292 

0.8156 

S15 

X(D=(Y (I)+Z(f) )*!/(/) 

0.05576 

0.06902 

0.1429 

0.6930 

0.1068 

0.5588 

S16 

x(r)=Y(D*u(D/Z(i) 

0.09142 

0.1375 

0.5239 

1.429 

0.4184 

1.153 

S17 

x(r)=Y(i)+u(D/Z(i) 

0.09121 

0.1306 

0.5211 

1.374 

0.4161 

1.150 

S18 

X(I)=Y(I)+R/Z( I) 

0.08302 

0.1267 

0.4898 

1.381 

0.3864 

1.134 

S19 

X(I)=R/Y(l)+R/Z(r) 

0.1251 

0.2184 

0.9023 

2.373 

0.7142 

1.955 

S20 

X(f)=R\/Y(f)+R2/Z(I) 

0.1245 

0.2204 

0.8984 

2.358 

0.7131 

1.892 

S21 

X(/)=/?*(l/T(/)+l/Z(/)) 

0.1317 

0.2475 

0.9320 

2.588 

0.7370 

2.085 

S22 

x([)=u(D/Y(n+U(r)/Z(r) 

0.1322 

0.2219 

0.9393 

2.400 

0.7362 

1.971 

S23 

X{J)=U\{D/Y (/)+(/2(/)/Z(/) 

0.1415 

0.2264 

0.9709 

2.442 

0.7731 

2.017 

S24 

X(D=U(D*(l/Y(I)+l/Z(I)) 

0.1335 

0.2483 

0.9409 

2.629 

0.7455 

2.147 


basic operations, such as assignment, add, 
multiply, and divide, understanding the 
performance of these “atomic” operations 
is crucial for fully utilizing a computer’s 
computational power. In this section, 24 
basic Fortran statements are analyzed from 
the assembler point of view (see Table 1). 

Vector assignment. Assignment SI in 
Table 1 is the simplest Fortran statement. 
The 3090 has two assembler vector in¬ 
structions: load vector T(7) (VLD) and 
store vector X(I ) (VSTD). These two in¬ 
structions are chained on the X-MP. 

Vector addition. There are three vector 
operations on the 3090 for S2: load Y(I) 
(VLD), add Y(J) and Z(/) (VAD), and store 
X{I) (VSTD); 3 N cycles are required to 
execute S2. However, the vector instruc¬ 
tions of two loads, one add, and one store 
are chained on the X-MP; only IN cycles 
are required. Therefore, the execution time 
for vector assignment and add are equiva¬ 
lent for long vectors, as shown in Table 3 
for vector length N equal to 1,024. 

Comparing the execution processes of 


S2 on the 3090 and the X-MP, you can see 
that the operands for arithmetic operations 
have to be streamed from registers on the 
X-MP, while the operands can flow di¬ 
rectly from the memory on the 3090. As 
mentioned before, the reasons for this are 
that the 3090 has fast cache memory and 
the time for data transfer between cache 
and functional units is equivalent to the 
time for data transfer between registers 
and functional units. However, the result 
of a vector operation is always put into a 
vector register on both the 3090 and the X- 
MP. 

There are one scalar and two vector 
operations on the 3090 for S3: load/? (LD), 
which takes only one cycle; add (VAD); 
and store (VSTD). Therefore, the CPU 
time for adding a scalar and a vector is less 
than that for adding two vectors, which 
takes three vector operations on the 3090. 

However, the scalar operation of load¬ 
ing scalar R, which takes 14 cycles on the 
X-MP, cannot chain with other vector 
operations, whereas, in S2, vectors Z(/) 
and //(/) are loaded simultaneously. There¬ 
fore, for short vectors, adding two vectors 


is faster than adding a scalar and a vector as 
shown in Table 3 for N equal to 6. Hence, 
you can gain speedup for short vectors by 
expanding the scalar R in S3 to a vector as 
in S2. 

The scalar expansion break-even length 
N for S3 is 128, as given in Table 5. But, the 
speed for the two aforementioned cases is 
exchanged for long vectors, as shown in 
Table 3 for N equal to 1,024. The reason for 
this is, although the overhead of the loop 
sectioning for long vector is significantly 
smaller than that on the 3090 because of 
chaining, it will compensate the cycles for 
loading a scalar. Therefore, the speed for 
adding two vectors will be slower than that 
for adding a scalar and a vector for long 
vectors on the X-MP. 

Vector multiplication. Due to vector 
pipelining, vector multiply operations S4 
and S5 should take the same amount of 
time as add operations S2 and S3 for long 
vectors. This conclusion is supported by 
the CPU time shown in Table 2 and Table 
3 for N equal to 1,024 on the 3090 and the 
X-MP, respectively. The time required to 
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Table 3. The CPU time (in seconds) for the Fortran kernels in both vector and scalar modes with different vector lengths N 


on the Cray X-MP. 


No. 

Vector Operations 

N= 6 

Vector 

(*10-*) 

Scalar 

(-10- 4 ) 

N= 

Vector 

(*1Q- 4 ) 

=64 

Scalar 
(* 10 -4 ) 

N= 1 
Vector 
(*10- 3 ) 

1024 

Scalar 

(*10“ 3 ) 

SI 

X(T)=Y(T) 

0.00901 

0.01565 

0.01949 

0.1063 

0.02166 

0.1607 

S2 

X(I)=Y(I)+Z{i) 

0.01023 

0.02099 

0.02016 

0.1628 

0.02293 

0.2513 

S3 

X(D=R+U(I) 

0.01097 

0.01929 

0.02083 

0.1395 

0.02154 

0.2139 

S4 

X([)=Y(I)*Z(I) 

0.01032 

0.02136 

0.02046 

0.1678 

0.02300 

0.2598 

S5 

X(I)=R*U(I) 

0.01105 

0.02002 

0.02075 

0.1447 

0.02143 

0.2208 

S6 

X(I)=Y(I)IZ(D 

0.01295 

0.03355 

0.03351 

0.2971 

0.04393 

0.4652 

S7 

x(r>=R/u(i) 

0.01407 

0.03424 

0.03411 

0.2978 

0.04292 

0.4648 

S8 

X(J)=Y(J)+Z(J)*U(J) 

0.01104 

0.02471 

0.02636 

0.2008 

0.03209 

0.3131 

S9 

X(J)=Y(r)+R*Z(I) 

0.01199 

0.02343 

0.02156 

0.1782 

0.02250 

0.2753 

S10 

X(r)=R*Yd)+R*Z(l) 

0.01273 

0.02553 

0.02385 

0.2026 

0.02628 

0.3122 

Sll 

X(I)=R\*Y(l)+R2*Z(l) 

0.01290 

0.02569 

0.02397 

0.2018 

0.02634 

0.3114 

S12 

X{t)=(Y(I)+Z{1))*R 

0.01226 

0.02554 

0.02176 

0.2021 

0.02317 

0.3119 

S13 

X(I)=U(D*Y(n+U(f)*Z(I) 

0.01174 

0.02686 

0.02623 

0.2242 

0.03221 

0.3483 

S14 

X(I)=U \(/)* Y(f)+U2(F)*Z(J) 

0.01276 

0.02939 

0.02699 

0.2477 

0.03283 

0.3863 

S15 

X(I)=(Y(f)+Z(I))* U (/) 

0.01111 

0.02474 

0.02648 

0.2018 

0.03207 

0.3128 

S16 

X(/)=T(/)*U(/)/Z(/) 

0.01445 

0.03415 

0.03951 

0.2999 

0.05214 

0.4695 

S17 

x(/)=y(/)+t/(/)/z(/) 

0.01363 

0.03657 

0.03367 

0.3288 

0.04450 

0.5168 

S18 

X(r)=Y(I)+R/Z(I) 

0.01518 

0.03754 

0.03526 

0.3294 

0.04463 

0.5168 

S19 

Xd)=R/Y(!)+R/Z([) 

0.01763 

0.03977 

0.05260 

0.3538 

0.07246 

0.5564 

S20 

X(r)=R\/Y d)+R2/Z(l) 

0.01779 

0.03996 

0.05277 

0.3539 

0.07339 

0.5558 

S21 

x(/)=x*(i/y(/)+i/z(/)) 

0.01671 

0.03979 

0.04627 

0.3541 

0.06285 

0.5554 

S22 

x(i)=U(r)IY(D+u(i)/z(o 

0.01753 

0.04108 

0.05291 

0.3771 

0.07470 

0.5927 

S23 

x(/)=[/i(/)/y(/)+U 2 (/)/z(/) 

0.01743 

0.04152 

0.05212 

0.3773 

0.07438 

0.5916 

S24 

X(I)=U(D*i\IY{I)+\IZ(I)) 

0.01584 

0.03882 

0.04480 

0.3531 

0.06209 

0.5542 


start up pipelines on the X-MP is much less 
than that on the 3090. Initiating the multi¬ 
ply pipeline takes only one cycle for the 
steering module on the X-MP. The scalar 
expansion break-even length of S5 is 64 
(Table 5). 

Vector division. Unlike vector load, 
store, add, and multiply operations, which 
can be pipelined such that one result is 
produced per cycle after startup, divide 
operation S6 cannot produce one result per 
cycle. For example, the division algorithm 
the X-MP used is based on Newton’s 
method and consists of four vector 
operations. The first operation is per¬ 
formed in the reciprocal functional unit, 
where one result is produced after 14 
cycles delay, followed by three vector 
operations performed in the floating-point 
multiply functional unit in iteration mode, 
full-precision mode, and full-precision 
rounded mode, respectively. 

Compared with the assignment, multi¬ 
ply, and add operations, the X-MP takes 
about two cycles to get one result for the 
divide pipeline, as shown in Table 3 for 


vector length N equal to 1,024. It takes 2N 
cycles to execute vector assignment SI 
(load and store) on the 3090, according to 
the CPU time for divide and assignment 
operation with N equal to 1,024 in Table 2. 
Assuming the overheads for both SI and 
S6 are the same, you can calculate that it 
takes about 17.4 cycles to produce one 
result for the divide pipeline (VDD) on the 
3090 in contrast to theoretically 15 and 30 
cycles, respectively, in vector and scalar 
modes. 

This technique can also be used to calcu¬ 
late the execution cycles for other tran¬ 
scendental operations, such as exponential 
and trigonometrical operations. But, the 
point is, you had better know how an indi¬ 
vidual algorithm is implemented in a vec¬ 
tor processor to write efficient codes that 
can take advantage of all possible chaining 
operations for improving the performance 
of a program. 

There are two vector operations (divide 
and store) on the 3090 for S7. The time for 
loading a scalar R is negligible for long 
vectors. Similar to multiply, dividing a 
scalar by a vector is always faster than 


dividing a vector by a vector on the 3090. 

On the X-MP, due to chaining of two 
loads, dividing a scalar by a vector is 
equivalent to dividing a vector by a vector. 
In both cases, the speed depends on the 
vector length similar to the case of multi¬ 
ply. At this point, I should point out that 
dividing a vector by a scalar is equivalent 
to multiplying the vector by the reciprocal 
of the scalar. Because the divide operation 
is so expensive, optimized Fortran compil¬ 
ers usually avoid generating divide assem¬ 
bler instructions. Therefore, operations 
such asX(/) = U(l)/R are excluded from the 
testing Fortran kernels. 

Vector addition and multiplication. 

There are four vector instructions for S8 on 
the 3090: load Z(/), multiply, add, and 
store. Even though the 3090 is potentially 
capable of chaining one multiply and one 
add, no chaining operations occur in this 
case. If chained operation VMAD occurred 
in S8, it would be executed as follows: load 
T(/), loadZ(/), multiply and add, storeX(/). 
Therefore, four vector operations would be 
required in any case. Since the X-MP can 


September 1989 


39 






Table 4. The scalar to vector speed-up for the vector arithmetic operations with different vector lengths N on the IBM 3090 
and the Cray X-MP, and the CPU ratio of the 3090 to the X-MP for N equal to 1,024. 


No. 

Vector Operations 

N= 12 

IBM 

W=128 

V= 1,024 

N= 6 

Cray 

1V=64 

W= 1,024 

IBM/Cray 

Vector Scalar 

SI 

X(D=Y(I) 

0.96 

4.17 

5.00 

1.74 

5.45 

7.42 

2.52 

1.70 

S2 

X{I)-Y{I)+Z(D 

1.05 

4.31 

4.97 

2.05 

8.08 

10.96 

3.44 

1.56 

S3 

X(I)=R+U(I) 

1.30 

5.91 

7.08 

1.76 

6.70 

9.93 

2.55 

1.82 

S4 

X(D=Y(D*Z(D 

1.16 

4.81 

5.53 

2.07 

8.20 

11.30 

3.48 

1.70 

S5 

X(I)=R*U(I) 

1.41 

6.55 

7.85 

1.81 

6.97 

10.30 

2.59 

1.98 

S6 

X(/)=T(/)/Z(/) 

1.43 

2.48 

2.60 

2.59 

8.87 

10.59 

8.75 

2.15 

S7 

X([)=R/U(f) 

1.58 

2.66 

2.80 

2.43 

8.73 

10.83 

8.37 

2.17 

S8 

X(I)=Y(I)+Z(J)*U([) 

1.24 

4.62 

5.34 

2.24 

7.62 

9.76 

3.24 

1.77 

S9 

X(I)=Y(I)+R*Z(I) 

1.42 

5.70 

6.85 

1.95 

8.27 

12.24 

3.56 

2.00 

S10 

X(I)=R*Y(I)+R*Z(I) 

1.95 

7.98 

10.02 

2.01 

8.49 

11.88 

3.07 

2.59 

Sll 

X(I)=R\*Y{I)+R2*Z(J) 

2.01 

8.26 

9.61 

1.99 

8.42 

11.82 

3.08 

2.51 

S12 

X(I)={Y{I)+Z(I))*R 

1.25 

4.86 

5.32 

2.08 

9.29 

13.46 

4.39 

1.74 

S13 

X(I)=U(D*Y(D+U(I)*Z(D 

1.72 

6.89 

7.44 

2.29 

8.55 

10.81 

3.35 

2.30 

S14 

X(I)=Um*Y(I)+U2(I)*Z(r) 

1.47 

5.72 

6.31 

2.30 

9.18 

11.77 

3.94 

2.11 

S15 

X(J)=(Y([)+Z(I))*U(I) 

1.24 

4.85 

5.23 

2.23 

7.62 

9.75 

3.33 . 

1.79 

S16 

X(J)=Y(D*U(!)/Z(D 

1.50 

2.73 

2.76 

2.36 

7.59 

9.00 

8.02 

2.46 

S17 

X(D=Y(D+U(r)/Z(f) 

1.43 

2.64 

2.76 

2.68 

9.77 

11.61 

9.35 

2.23 

S18 

X(I)=Y(I)+R/Z(I) 

1.53 

2.82 

2.93 

2.47 

9.34 

11.58 

8.66 

2.19 

S19 

X(I)=R/Y(D+R/Z(I) 

1.75 

2.63 

2.74 

2.26 

6.73 

7.68 

9.87 

3.51 

S20 

X(I)=R\/Y (I)+R2/Z( I) 

1.77 

2.62 

2.65 

2.25 

6.71 

7.57 

9.72 

3.40 

S21 

X(/)=/?*(l/y(7)+l/Z(/)) 

1.87 

2.78 

2.83 

2.38 

7.65 

8.84 

11.72 

3.75 

S22 

X(I)=U(I)/Y(n+U(I)/Z(0 

1.68 

2.56 

2.68 

2.34 

7.13 

7.93 

9.86 

3.33 

S23 

X(I)=Ul(f)/Y(D+U2(I)/Z(f) 

1.60 

2.52 

2.61 

2.38 

7.24 

7.95 

10.39 

3.41 

S24 

x(/)=(/(/)*(i/y(/)+i/z(/)) 

1.86 

2.79 

2.88 

2.45 

7.88 

8.93 

12.01 

3.87 


only chain two loads, one store, one add, 
and one multiply, all operands of arithme¬ 
tic operations have to be loaded into the 
vector registers. Therefore, 2N cycles are 
required for S8. 

On the 3090, there are one scalar and 
three vector operations for S9: load R (1 
cycle), multiply, add, and store. For long 
vectors, the ratio of the execution cycles 
between S9 and S8 is 3N/4N = 0.75 and the 
ratio of the CPU time is 0.77, according to 
the data in Table 2 for vector length N 
equal to 1,024. 

On the X-MP, after loading scalar R ( 14 
cycles), five vector operations, loads Y(l) 
and Z(/), multiply, add, and store, will 
proceed concurrently. Therefore, only IN 
cycles are required to execute S9 for long 
vectors. 

Since the X-MP can only load two vec¬ 
tors simultaneously, the scalar expansion 
break-even length for S9 is relatively short 
(Table 5). 

On the 3090, S10 is executed as follows: 
first, load scalar!? (LD); second, multiply 
R by the vector T(/) (VMD); third, follow 
up with a chained vector operation 
VMADS, which does multiply and add 


simultaneously; and fourth, store X([) 
(VSTD). Since there are three vector in¬ 
structions, it takes about the same amount 
of CPU time for S9 and S10 if the vector 
length is long enough to overcome the 
start-up overhead. Instead of a chained 
vector operation VMADS, all vector in¬ 
structions are simple for executing S9; 
therefore, S9 noticeably takes relatively 
less CPU time than S10 for short vectors. 
These conclusions are supported by the 
data in Table 2. 

Another important result is that, to bene¬ 
fit from a chained vector operation 
VMADS, the vector addend has to be al¬ 
ready loaded into a vector register since 
VMADS is equivalent to a simple multiply 
(without load) followed by an add. 

On the X-MP, two vector multiply op¬ 
erations, which invoke the same functional 
unit, cannot chain. Hence, 2N cycles are 
required for S10. Then, the difference of 
the CPU time for S8 and S10 should be 
very small. 

However, the testing results in Table 3 
show that S10 takes noticeably less CPU 
time than S8 for long vectors. One reason 
is that using the same functional unit 


(multiply functional unit is used here) 
continuously reduces the pipelining over¬ 
head. The main reason is that, since the X- 
MP can only load two vectors simultane¬ 
ously, loading three vectors in S8 seriously 
slows down the speed of the vector 
operation. 

Sll is similar to S10. The vector 
operations are not changed, except that 
two scalar multipliers (instead of one) are 
loaded sequentially. Since the 3090 uses 
fast memory cache, the difference of the 
CPU time between S11 and S10 is only one 
cycle, which is negligible. But, on the X- 
MP, it takes an extra 14 cycles to load the 
second scalar. The difference of the CPU 
time between these two cases will be sig¬ 
nificant for short vectors and negligible for 
long vectors (Table 3). 

For an arithmetic operation on the 3090, 
such as add and multiply, one of two oper¬ 
ands has to be already in a register. If an 
operation involves both a scalar and a 
vector, the scalar will be loaded since it 
only takes one cycle; if both operands are 
vectors, IN cycles are required to load a 
vector from memory into a V register. 
Although the floating-point operations of 
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Table 5. The scalar expansion break-even length N for the Fortran kernels on 
the Cray X-MP. 


No. 

Vector and Scalar Operations 

N 

S2 

X(P)=Y{I)+Z(I) 

128 

S3 

X(r)=R+U(I) 


S4 

X(I)=Y{I)*Z{1) 

64 

S5 

X(I)=R*U(T) 


S6 

X(I)=Y(I)IZ(I) 

192 

S7 

X(I)=R/U(D 


S8 

X(D=Y(l)+Z(D*U(I) 

16 

S9 

X(l)=Y(D+R*Z(I) 


S13 

X(I)=U(l)*Y(I)+U(D*Z(I) 

38 

S10 

X(I)=R*Y(1)+R*Z{1) 


S14 

X(J)=U\(J)*Y(J)+U2(J)*Z(I) 

36 

Sll 

X(I)=R\*Y(I)+R2*Z(r) 


S15 

X(D=(Y(I)+Z(I))*U(I) 

17 

S12 

X(D=(Y(I)+Z(I))*R 


S17 

x(D=Y(r)+U(f)/z(i) 

None 

S18 

X(r)=Yd)+R/z(D 


S22 

X(D=U{P>IY{I)+W)W) 

47 

S19 

X(I)=RIY{I)+RIZ(D 


S23 

x(i)=um/Y(D+U2(r)/z(r) 

47 

S20 

X(r)=Rl/Y(I)+R2/Z(I) 


S24 

x(i)=u(i)*( i/y(/)+ 1 /z(D) 

81 

S21 

x(/)=/f*(i/y(/)+i/z(/)> 



both S12 and S9 are the same, there are 
four vector operations for S12—load Y(l), 
add, multiply, and store — instead of three 
vector operations for S9 on the 3090. 
Therefore, S12 takes more CPU time than 
S10. The CPU time required for S12 is 
equivalent to the CPU time for S8 since the 
number of the vector operations for both 
statements is the same. 

On the X-MP, there are one scalar 
operation (load R) and chained vector 
operations: vector load, add, multiply, and 
store, which use different functional units. 
It takes IN cycles to process the loop 
equivalent to S9. Although the order of the 
multiply and add is changed in S12 and S9, 
the CPU times are almost the same for both 
cases, especially for long vectors (Table 
3). Hence, the order of vector multiply and 
add does not affect the chaining perfor¬ 
mance on the X-MP, whereas it does on the 
3090. 

On the 3090, there are four vector 
operations for S13: load £/(/), multiply, 
multiply and add (VMAD), and store. 
Although the number of vector operations 
is the same for S8 and SI3, the CPU time 
between these two cases is noticeable for 
short vectors because the pipelining over¬ 
head of the chained operation VMAD is 
more significant than the simple vector 
operation VMD. On the X-MP, both S13 
and S8 take 2 N cycles, which is supported 
by the CPU time in Table 3. 

Since the two multipliers are different 
vectors in S14, the 3090 has to load two 
vectors Y(I) and Z(7) from the memory into 
the vector register instead of only one load 
U(I) as in SI3. The ratio of the vector 
operations between S13 and S14 is 4N/5N 
= 0.8, which is compatible with the ratio 
0.83 of the CPU time for vector length N 
equal to 1,024. Due to chaining of two 
vector loads, the execution cycles are the 
same for both S14 and S13 on the X-MP, as 
shown by the CPU time in Table 3. 

Unlike S10 and SI2, the number of 
vector operations for S15, S13, and S8 is 
the same on the 3090. The CPU time for 
these three cases is about the same for long 
vectors, as shown in Table 2 for N equal to 
1,024. On the X-MP, the vector operation 
process for S15 is equivalent to S8 except 
for the change of the execution sequence 
that has little effect on the CPU time. The 
CPU times for both cases are equivalent 
regardless of the vector length (Table 3). 

Vector addition, multiplication, and 
division. The integer 1 in S21 and S24 is 
replaced in the Fortran statement by 1 .DO 
on the 3090 and 1 .E0 on the X-MP. 


There are four vector operations for S17 
on the 3090: load U{T), divide, add, and 
store. The X-MP is capable of chaining 
two loads, one store, one add, one multi¬ 
ply, and one reciprocal approximation; 
then four loads, one store, two adds, and 
one divide can proceed in two cycles after 
start-up. Hence, both S17 and S18 take 2 N 
cycles for long vectors without consider¬ 
ing the cycles for loading scalar /? (14 
cycles) in SI8. Therefore, the CPU times 
are equivalent for both cases, as in Table 3 
for N equal to 1,024. 

Due to the chaining of one add and one 
divide vector operations, the CPU time for 
S17 and S18 are equivalent to the time for 
S6 and S7, as in Table 3 for a vector length 
of 1,024. 

Since the implementation of the divide 
algorithm uses the multiply functional unit 
on the X-MP, as mentioned before, chain¬ 


ing of divide and multiply operations will 
not occur. This assertion is supported by 
the CPU timeforS16,S17, and S6 in Table 
3 for vector length N equal to 1,024. Note 
that the CPU time for S16 in scalar mode is 
surprisingly less than that for S17 and S18, 
regardless of the vector length. Therefore, 
the corresponding vector speedup for S16 
is relatively small compared with the 
speedupforS17 andS18 (Tables 3 and 4). 

On the 3090, there are four vector opera¬ 
tions for S19: divide, divide, add, and store. 
But, five vector operations — divide, di¬ 
vide, add, multiply, and store — are re¬ 
quired for S21. Therefore, S19 takes less 
CPU time on the 3090. However, both S22 
and S24 require five vector operations, 
which are load (/(/), divide, divide, add, 
and store for S22; and divide, divide, add, 
multiply, and store for S24. Hence, the 
CPU times for S22 and S24 are equivalent 
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Table 6. The speed hierarchy of the Fortran kernels relative to vector assignment in different vector lengths and the vector 
break-even length (Vbel) N on the IBM 3090 and Cray X-MP. 


No. 

Vector Operations 

N= 12 

IBM 

V=128 

N= 1,024 

N=6 

Cray 
N= 64 

N= 1,024 

Vbel N 
IBM 

Cray 

SI 

X(I)=Y(D 

1 

! 

1 

! 

1 

1 

13 

2 

S2 

X(D=Y(I)+Z(D 

4 

4 

4 

2 

2 

5 

12 

2 

S3 

X(I)=R+U(I) 

2 

2 

2 

4 

5 

3 

10 

2 

S4 

x(D=Y(f)*z(r> 

5 

5 

5 

3 

3 

6 

10 

2 

S5 

x(i)=R*u(r) 

3 

3 

3 

6 

4 

2 

8 

2 

S6 

X(D=Y(i)/z(D 

15 

15 

15 

14 

12 

15 

7 

2 

S7 

X(D=R/U(D 

14 

14 

14 

16 

16 

14 

6 

2 

S8 

X(I)=Y(I)+Z(l) * U (/) 

10 

12 

12 

5 

9 

10 

11 

2 

S9 

X(I)=Y(I)+R*Z(l) 

6 

6 

6 

9 

6 

4 

10 

2 

S10 

X(J)=R*Y(J)+R*Z(J) 

7 

7 

7 

11 

14 

8 

6 

2 

Sll 

X(I)=R\ *Y(I)+R2*Z(I) 

8 

8 

8 

13 

15 

9 

6 

2 

S12 

X(r)=(Y([)+Z(I))*R 

9 

9 

9 

10 

7 

7 

9 

2 

S13 

X(I)=U(I)*Y(I)+U(I)*Z(I) 

12 

11 

11 

8 

8 

11 

7 

2 

S14 

x(j)=u\(i)*Y(D+u2{i)*z{r) 

13 

13 

13 

12 

11 

12 

8 

2 

S15 

X(D=(Y(I)+Z(l))*U(I) 

11 

10 

10 

7 

10 

13 

10 

2 

S16 

X(n=Y([)*u(r)/z(j) 

18 

18 

18 

17 

18 

18 

6 

2 

S17 

X(J)=Y(!)+U{I)IZ(J) 

17 

17 

17 

15 

13 

16 

8 

2 

S18 

X(I)=Y(I)+R/Z(I) 

16 

16 

16 

18 

17 

17 

6 

2 

S19 

X(I)=R/Y(f)+R/Z(r) ■ 

20 

20 

20 

23 

22 

21 

5 

2 

S20 

X(I)=R\IY{I)+R2/Z(I) 

19 

19 

19 

24 

23 

22 

5 

2 

S21 

X(/)=«*(l/T(/)+l/Z(/)) 

21 

21 

21 

20 

20 

20 

5 

2 

S22 

X(l)=U(DIY(I)+U(I)IZ(I) 

22 

22 

22 

22 

24 

24 

5 

2 

S23 

X{l)=U\(I)/Y(D+U2(I)/Z(I) 

24 

24 

24 

21 

21 

23 

6 

2 

S24 

X(/)=t/(/)*(l/T(/)+l/Z(7)) 

23 

23 

23 

19 

19 

19 

5 

2 


(Table 2). On the X-MP, the floating-point 
multiply functional unit is invoked twice 
for the reciprocal operation instead of three 
times for the divide operation. Therefore, 
due to vector chaining, S21 and S24 take 
less CPU time than the equivalent state¬ 
ments S19 and S22, respectively, regard¬ 
less of the vector length (Table 3). 

Suggestions for 
vectorization on the 
3090 and X-MP 

Based on the discussions above, the 
following suggestions for users can be set 
down for successful vectorization on the 
3090 and X-MP, from the vector chaining 
point of view: 

(a) Long vectors are required to over¬ 
come the pipelining overhead. The vector 
break-even lengths for the vector arithme¬ 
tic operations tested on both the 3090 and 
the X-MP are given in Table 6. The maxi¬ 
mum vector break-even length on the 3090 
is 13 for the assignment statement. There¬ 
fore, a loop with vector length longer than 


13 will speed up in vector mode. 

The vector break-even lengths for the 
statements with compound vector 
operations such asX(/) =R* Y([) +R* Z(l) 
and X(I) = Rl * Y(I) + R2*Z(I) are shorter 
than the statements without chaining 
operations such asX(7) = (Y(I) + Z(I) * U(I) 
and X(I) = Y(I) + R* Z(J). Therefore, the 
vector break-even lengths depend on the 
chainability of the vector operations. 

Since the scalar add operation is more 
efficient than the scalar multiply 
operation, the vector break-even length for 
add is longer than that for multiply because 
the times for both the add operation and the 
multiply operation in vector mode are 
almost the same due to vector pipelining. 
Even though the divide pipeline takes 17.4 
cycles to produce one result, the vector 
divide is superior to the corresponding 
scalar divide operation. As shown in Table 
6, the vector break-even length for the 
divide operation is relatively small com¬ 
pared with other vector operations. Due to 
vector chaining, the speed in vector mode 
is always faster than the speed in the corre¬ 
sponding scalar mode on the X-MP, even 
for the vector length of 2. 


Table 4 shows that the longer the vector 
length, the larger the speedup. However, 
for long vectors, the cache degradation and 
memory contention, which in certain cases 
comprise the major bottleneck for a pro¬ 
gram, should be carefully considered for 
the 3090 and X-MP. For example, in ma¬ 
trix calculations, the column reference 
should be used instead of the row reference 
to improve the locality of the data. 

(b) Due to vector pipelining and chain¬ 
ing, the load and store operations take 
about the same execution time as the float¬ 
ing-point add and multiply operations. 
Counting the number of arithmetic 
operations, the conventional method for 
evaluating the computational complexity 
of a program, works for scalar machines, 
but it may not be valid for a vector proces¬ 
sor. Mstmts seems to better characterize 
the performance of the Fortran kernels than 
Mflops (Table 1). 

Since most engineering and scientific 
calculations are composed of sequences of 
the vector arithmetic operations tested, the 
speed hierarchy of these operations is 
given in Table 6. Using this table, one can 
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write a program that will match the archi¬ 
tecture to a certain extent. For example, the 
constructs of X(I) =R* y(/) +R* Z(l) and 
X(l) = U(I)/Y(I) + U(I)IZ(I) should be used 
on the 3090, whereas the constructs X(I) = 
R * (Y{I) + Z(I)) and X(I) = U(I) * (\IY (I) + 
1/Z(/)) will give better performance on the 
X-MP. 

(c) The order of vector multiply and add 
does not affect the chaining performance 
on the X-MP, whereas it does on the 3090. 
For add or multiply operation, one of two 
operands has to be loaded into the register, 
and the second operand can be streamed 
directly from the cache memory. If the 
operation involves both a scalar and a 
vector, the scalar is loaded, which takes 
only one cycle. If both operands are vec¬ 
tors, IN cycles are required to load one of 
the operand vectors. 

Comparing the CPU time for vector 
assignment, add, and multiply operations, 
the X-MP scalar performance is not attrac¬ 
tive. For example, the ratio of the CPU 
time of the 3090 to the X-MP is 1.56 to add 
two vectors in scalar mode with vector 
length of 1,024, in contrast to the cycle 
ratio 2.18 of two machines. 

But, vector chaining improves the vec¬ 
tor performance of the X-MP dramatically. 
The CPU ratio of the 3090 to the X-MP in 
vector mode is always larger than that in 
scalar mode, as shown in Table 4 for vector 
length 1,024. 

The vector operations invoking the 
compound instruction (VM AD) have rela¬ 
tively high speedup on the 3090. For ex¬ 
ample, among all the tested Fortran codes, 
the vector operation X(I) =R* Y(I) + Z(/) 
* R has the highest speedup 10.02 for 
vector length 1,024, which is comparable 
to the speedup on the X-MP. 

To obtain the chained vector operation 
VMAD on the 3090, the addend has to be 
already loaded into a vector register. This 
can be accomplished in certain cases by 
using the distributive law as shown in S10 
and SI2. 

The more complicated the expressions, 
the more you can take advantage of the 
chainabilities, as shown by the Mflops on 
the X-MP in Table 1; as such, the simple 
statements should also be combined into a 
complicated statement whenever possible. 

This can also save time for storing, 
which costs the same time as the computa¬ 
tional operations. For example, although 
the most operations of Unpack 2 and Liver¬ 
more Loops 3 belong to the Fortran kernels 
tested, many vector loops have more than 
10 floating-point operations in a single 


statement. The vector processor with 
chaining abilities can easily enhance the 
vector performance for those vector loops. 

Since the X-MP is capable of chaining 
two loads, one store, one add, one multi¬ 
ply, one reciprocal approximation, etc., the 
expression with even vector loads and odd 
add and multiply can take full advantage of 
the chaining abilities of the X-MP. For 
example, the CPU time for vector 
operations with vector loading numbers 
less than or equal to two, X(I) = Y(l), Y(I) + 
Z(I), R + (/(/), Y(I) * Z(I), R * Z(I), Y(l) + 
R * Z(J),R * Y(l) + R * Z(I), R 1 * Y(I) + R2 
* Z(I), and (Y(I) + Z(/)) * R, are in the same 
order while the vector operations with 
vector loading number more than two, X(f) 
= Y(D + Z(J) * U(D, U([) * Y(D + U(D * 
Z(7), m (/) * Y(D + U2(0 * Z(D, and (Y(I) 
+ Z(/)) * !/(/), are in another level for 
vector length 1,024 (Table 3). 

(d) The divide operation takes about 
17.4 and 2 cycles to produce one result on 
the 3090 and X-MP, respectively. Even 
though the vector break-even lengths for 
divide operations are relatively short on 
the 3090 (Table 6), the vector divide 
operation is very inefficient. 

The maximum speedup of all tested 
Fortran codes with divide operations is 
less than 3, and the speedup of the divide 
operation almost reaches the maximum 
value for vector length of 128 (Table 4). 
Therefore, the divide operations should be 
avoided whenever possible on the 3090. 

The speedup of the divide operations on 
the X-MP is equivalent to the speedup of 
the add and multiply operations. There¬ 
fore, the CPU ratio of the 3090 to the X-MP 
is relatively high for Fortran kernels in¬ 
volving divide operations, as shown in 
Table 4 for vector length 1,024. 

Since the divide operation uses the float¬ 
ing-point multiply functional unit on the 
X-MP, both divide and multiply operations 
such as X(I) = Y([) * U(I)/Z(I) should, 
whenever possible, not appear together in 
a statement. However, on the X-MP, four 
loads, one store, two adds, one divide, etc. 
can be processed concurrently. For ex¬ 
ample, the execution times forX(7) = Y(I)/ 
Z(I) and X(I) = Y(I) + t/(/)/Z(/) are almost 
the same for vector length of 1,024. The 
add operation in S17 doesn’t cost extra 
CPU time compared to S6. Therefore, the 
vector operation X(/) = Y(f) + U(I)IZ(I) has 
relatively high speedup. 

(e) Loading operands from memory to 
registers is very expensive on the X-MP; it 
takes 14 cycles to load a scalar and 17 


cycles to load the first element of a vector. 
Therefore, for calculations involving both 
scalars and vectors, one can gain speedup 
by expanding scalars to vectors for short 
vectors. 

However, due to the overhead of the 
loop sectioning, expanding scalars to vec¬ 
tors will not gain speedup for vectors 
longer than certain lengths. The scalar 
expansion break-even lengths for the 
tested Fortran kernels are given in Table 5. 
Since loading a scalar from the fast cache 
memory only takes one cycle on the 3090, 
the arithmetic vector operations with all 
vector operands take more CPU time than 
the corresponding vector operations in¬ 
volving both scalars and vectors, regard¬ 
less of the vector lengths on the 3090. 

Based on the tests, not only can we 
obtain the above vectorization techniques 
for machine users, but also make sugges¬ 
tions for machine designers. The final 
product may have to compromise the fac¬ 
tors such as the cost of the machine, com¬ 
plexity of the machine organization, and 
benefit of the special architectures. The 
following vectorization suggestions for 
machine designers from the vector chain¬ 
ing point of view are based on the current 
machine organizations of the 3090 and X- 
MP, using only one add and one multiply 
functional units. 

(f) The dataflow from the memory is the 
major bottleneck for the 3090 and X-MP 
systems. Without undergoing major 
changes of the machine organization, but 
only adding extra paths for transferring the 
data between the memory and CPU, the 
performance of the machine could be 
improved significantly. 

The X-MP can only chain two vector 
loads; namely, only two vector data 
streams can be provided for the CPU. If the 
operations involve more than two vectors, 
the vector performance will be limited 
because the data is unavailable when it is 
required forprocessing. Forexample, even 
though the vector operation X(f) = R* Y(F) 
+ R * Z(I) has two vector multiply 
operations, its CPU time is much less than 
the vector operation X(I) = Y(F) + Z(/) * 
U(I) because three vectors cannot be 
loaded concurrently on the X-MP. 

Were a machine capable of chaining 
three loads and other operations, one result 
of vector operations such as X(f) = Y([) + 
Z(I) * U(I) and X(f) = (Y(I) + Z(/» * U{I) 
could be produced per cycle. Since most 
calculations involve both add and multiply 
operations, each operation requires two 
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operands. If a machine such as the X-MP 
could chain four loads, the following For¬ 
tran code would be executed in 2N cycles: 

Do 3001 = 1,1V 
300 X(I) = 

YU) * ZU) * W(I) + (1/(0 + V(0) 

FirstiV cycles: load Y(I), Z(I), U(I), and 
V(I); multiply Y(l) * Z(7); add U(l) + V(I). 

Second N cycles: load W(I)\ multiply; 
add; store. 

Since the X-MP can only chain two 
loads currently, 3 N cycles are required to 
execute the above Fortran code. 

The IBM 3090 has only one data path. If 
it had two data paths accessible to both 
load and store, the statement such as X(I) = 
Y(I) + Z(7) * 7/(7) could be executed as 
follows: after vectors Y(l) and Z(/) are 
loaded into the vector registers, the multi¬ 
plicand vector 7/(7) is fetched directly from 
the cache memory and multiplied with the 
vector Z(/), followed by add operation 
(VMAD), then the result vector X{I) is 
stored into the memory. The load of Z(/), 
multiply Z(7) * U{1 ), add, and store of X(I) 
proceed concurrently after the pipeline 
start-up delay. Therefore, 2/V cycles would 
be required for the vector length of N if the 
start-up delay was ignored. 

However, if the 3090 had three load 
paths and one store path, the execution of 
the above statement could be started as 
follows: at first, load vectors Y(J) and Z(J) 
into the vector registers; after the first 
elements of Y{I) and Z(7) are loaded, the 
multiplicand 77(1) is fetched directly from 
cache memory and multiply with Z(l) 
before the loading of Y(2) and Z(2) is 
completed; followed by add operation; 
then store the result X(l). 

All other elements of the vector X(7) can 
be produced in the same manner. There¬ 
fore, one result could be produced per 
cycle after start-up delay. 

(g) To chain the vector operations in 
different statements within a loop, which is 
especially useful for a loop with many 
simple statements such as assignment, add, 
and multiply, etc., and to take full advan¬ 
tage of functional units, a machine should 
be capable of chaining four loads, two 
stores, one multiply, one add, one recipro¬ 
cal approximation, and other operations. If 
a machine had these chaining powers, the 
Fortran code such as 

Do 400/= l,N 
X(I) = Y(I) * Z(I) 

400 W(I) = 77(7) + V(I) 
could be executed in IN cycles only. 


T o obtain the best performance on 
vector processors, a program has 
to be written to match the indi¬ 
vidual machine architecture. The speed-up 
of a given code depends on both scalar and 
vector performance. 

If a program can take more advantage of 
the vector architecture, the speed-up will 
be greater. The potential gain will be great¬ 
est when a program can take full advantage 
of the chaining abilities of a vector proces¬ 
sor, which allows several instructions to be 
executed concurrently and several results 
to be produced per cycle. 

In this article, I have discussed program¬ 
ming techniques for invoking the chaining 
operations on the 3090 and the X-MP. The 
accompanying tables of the vector break¬ 
even lengths, scalar expansion break-even 
lengths, and speed hierarchy of the Fortran 
kernels can be used as guides to write a 
program that will match the machine archi¬ 
tecture to a certain extent. 

I have showed that the vector break¬ 
even lengths are shorter for chained vector 
operations, whereas the scalar expansion 
break-even length depends on the memory 
access speed. Also, a vector processor with 
one multiply and one add functional unit 
that was capable of chaining four loads, 
two stores, one add, one multiply, one 
reciprocal approximation, and other 
operations such as address operations, 
would provide the best performance from 
the chaining point of view. □ 
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A preemptive process migration 
facility in a distributed system 
dynamically relocates running 
processes among the component ma¬ 
chines. Such relocation can help cope with 
dynamic fluctuations in loads and service 
needs, 1 meet real-time scheduling dead¬ 
lines, bring a process to a special device, or 
improve the system’s fault tolerance. Yet, 
successful migration facilities are not com¬ 
mon in distributed operating systems, 2 ' 7 
due largely to the inherent complexity of 
such facilities and the potential execution 
penalty if the migration policy and mecha¬ 
nism are not tuned correctly. Not surpris¬ 
ingly, some operating systems terminate 
remote processes rather than rescue them 
by migration. 8 

There are several reasons why migration 
is hard to design and implement. The 
mechanism for moving processes must re¬ 
liably and efficiently detach a migrant 
process from its source environment, 
transfer it with its context (the per-process 
data structures held in the kernel), and 
attach it to a new environment on the des¬ 
tination machine. Migration may fail in 
case of machine and communication fail¬ 
ures, but it should do so completely. That 
is, the effect should be as if the process 
were never migrated at all or, at worst, as if 
the process had terminated due to machine 
failure. 


[ | 

Process migration is 
possible, if not always 
pleasant. The Charlotte 
migration protocol offers 
high code modularity 
and ease of maintenance 
while minimizing the 
impact of software and 
hardware failures. 


A wide range of migration policies 
might be needed, depending on whether 
the main concern is load sharing (avoiding 
idle time on one machine when another has 
a nontrivial work queue), load balancing 
(such as keeping the work queues similar 
in length), or application concurrency 
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(mapping application processes to ma¬ 
chines to achieve high parallelism). Poli¬ 
cies might need elaborate and timely state 
information, since unnecessary process 
relocations might otherwise degrade per¬ 
formance of both the migrant process and 
the entire system. 

The mechanisms to support different 
policies can differ significantly. If several 
policies are used under different circum¬ 
stances, the migration mechanism must be 
flexible enough to allow policy modules to 
switch policies. We cannot completely 
separate the migration mechanism from 
process scheduling, memory management, 
and interprocess communication. Never¬ 
theless, we prefer to keep mechanisms for 
these activities as separate as possible to 
allow more freedom in testing and upgrad¬ 
ing them. The fact that a process has moved 
should be invisible to both it and its peers, 
while interested users or processes should 
be able to advise the system about desired 
process distribution. 

This article discusses our experience 
with process migration in the Charlotte 
distributed operating system. Charlotte’s 
migration facility is a fairly elaborate addi¬ 
tion to the underlying kernel and utility- 
process base. It separates policy (when to 
migrate which process to what destination) 
from mechanism (how to detach, transfer, 
and reattach the migrant process). While 

47 


September 1989 


0018-9162/89/0900-0047$01.00 © 












Figure 1. Example of migration. 


the mechanism is fixed in the kernel and 
one of the utilities, the policy is relegated 
to a utility and can be replaced easily. The 
kernel provides elaborate state informa¬ 
tion to that utility. The mechanism allows 
concurrent multiple migrations and pre¬ 
mature cancellation of migration. It leaves 
no residual dependency on the source 
machine for the migrant process. The 
mechanism copes with all conceivable 
crash and termination scenarios, rescuing 
the migrant process in most cases. 

The following sections present an over¬ 
view of Charlotte, its process migration 
facility, and issues we encountered that 
have general application for any such facil¬ 
ity. In discussing each issue, we present 
alternative design approaches adopted by 
other process migration facilities. (A dis¬ 
cussion of specific migration policies is 
beyond the scope of this article.) We hope 
this account will help researchers contem¬ 
plating the addition of a process migration 
facility, as well as those designing other 
operating system facilities that might need 
to interact later with added process migra¬ 
tion facilities. 

Charlotte overview 

Charlotte is a message-based distributed 
operating system developed at the Univer¬ 
sity of Wisconsin for a multicomputer 
composed of 20 VAX-11/750 computers 
connected by a token ring. 9 Each machine 
in the multicomputer runs a kernel respon¬ 


sible for simple short-term process sched¬ 
uling and a message-based interprocess 
communication (IPC) protocol. Processes 
are not swapped to a backing store. A 
battery of privileged processes, called 
utilities, runs at the user level to provide 
additional operating system services and 
policies. The kernel and some utilities are 
multithreaded. 

Processes communicate via links, which 
are capabilities for duplex communication 
channels. (The Lynx 10 high-level language 
actually hides this low-level mechanism 
and provides a remote-procedure-call 
interface.) The processes at the two ends of 
a link can both send and receive messages 
using nonblocking service calls. A process 
can post several such requests and await 
their completion. It also can cancel a pend¬ 
ing request before the request completes. 
A link can be destroyed or given to another 
process, even during communication. In 
particular, a link is automatically de¬ 
stroyed when the process holding its other 
end terminates or when its machine 
crashes; the process holding the local link 
end is so notified by the kernel. 

The protocol that implements communi¬ 
cation semantics is efficient but quite com¬ 
plex." It depends on full, timely link infor¬ 
mation in the kernels supporting both ends 
of each link. Processes are completely 
unaware of the location of their communi¬ 
cating partners. Instead, they establish 
links to servers by having other processes 
(their parents or a name-server utility) 
provide them. 


Utility processes are distributed 
throughout the multicomputer. They coop¬ 
erate to allocate resources, provide file and 
connection services, and set policy. In 
particular, the KernJob utility runs on each 
machine to provide a communication path 
between the local kernel and nonlocal 
processes. The Starter utility creates proc¬ 
esses, allocates memory, and dictates 
medium-term scheduling policy. Each 
Starter process controls a subset of the 
machines, communicating with their ker¬ 
nels (directly or via their KernJobs) to 
receive state information and specify its 
decisions. 

Process migration 

We designed Charlotte as a platform for 
experimentation with distributed algo¬ 
rithms and load distribution strategies. We 
added the process migration facility to 
better support such experiments. Equally 
important, we wanted to explore design 
issues raised by process migration in a 
message-based operating system. Figure 1 
shows the effect of process migration. For 
convenience, we call the kernels on the 
source and destination machines S and D, 
respectively. P represents the migrant 
process, and KJ is the KernJob. 

During transfer. P’s process identifier 
changes, and the kernel data structures for 
it are completely removed from S, but the 
transfer is invisible to both P and its com¬ 
munication partners. As shown in Figure 1, 
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Table 1. Statistics collected by migration mechanism. 


Condition 

Action 

Significant event: message sent or 
received, data structure freed, process 
created or terminated 

Increment associated count 

Interval passes 

Sample process states and CPU, 
network loads 

Period of n intervals passes 

Summarize data, send to starter 


P’s links relocate to the new machine. All 
processes are unaware that link descriptors 
have moved and that local communication 
(performed in shared memory) has become 
remote communication (sent over the wire) 
and vice versa. The processes name their 
links the same after migration as before, 
and they see no change in message flow. 

Policy. Migration policy is dictated by 
Starter utility processes, which base their 
decisions on statistical information pro¬ 
vided by the kernels they control and on 
summary information they exchange 
among themselves. In addition. Starters 
accept advice from privileged utilities (to 
allow manual direction of migration and to 
enable or disable automatic control). A 
Starter process executes a policy proce¬ 
dure when it receives messages carrying 
statistics, advice, or notice of process crea¬ 
tion or termination. (Introducing migra¬ 
tion into the Starter only required writing 
the policy procedure and invoking it at the 
right times.) The policy procedure can 
choose to send messages to other Starters 
or to request some source kernel to under¬ 
take migration. Such requests are sent to 
the KernJob residing on the source ma¬ 
chine to relay to its kernel. As discussed 
later, this approach adds insignificantly to 
the cost of migration (a few procedure calls 
and perhaps a round-trip message), while it 
allows policies that integrate scheduling 
and memory allocation as well as local, 
clustered, or global policies. 

Mechanism. The migration mechanism 
has two independent parts: collecting sta¬ 
tistics and transferring processes. Both 
parts are implemented in the kernel. 

Statistics include data on machine load 
(number of processes, links, and CPU and 
network loads), individual processes (age, 
state, CPU utilization, and communication 
rate), and selected active links (packets 
sent and received). These statistics are 
intended to be comprehensive enough to 
support most conceivable policies. We 
collect statistics in several ways, as shown 
in Table 1. To balance accuracy with over¬ 
head, we used an interval of 50-80 milli¬ 
seconds and a period of 100 intervals (5-8 
seconds) in our tests. The overhead for 
collecting statistics was less than one per¬ 
cent of total CPU time. 

Process transfer occurs in three phases: 

(1) Negotiation. S and D, after being 
told by their controlling Starter processes 
to migrate P, agree to the transfer and 
reserve required resources. If agreement 


cannot be reached (for example, because 
resources are not available), the migration 
aborts and the Starter processes control¬ 
ling S and D are notified. 

(2) Transfer. P’s address space moves 
from the source to the destination machine. 
Meanwhile, each kernel controlling a proc¬ 
ess with a link to P receives separate mes¬ 
sages informing it of the link’s new ad¬ 
dress. 

(3) Establishment. Kernel data struc¬ 
tures pertaining to the migrant process 
are marshaled, transferred, and de- 
marshaled. (Marshaling involves copying 
the structure to a byte-stream buffer and 
converting some data types, particularly 
pointer types.) No information related to 
the migrant is retained at the source 
machine. 

Process-kernel interface. We added 
four kernel calls to the process-kernel 
interface: 

• Statistics(What : action; Where : ad¬ 
dress). The KernJob invokes this call on 
behalf of a Starter so that the kernel will 
start collecting statistics and placing them 
in the given address (in the KernJob virtual 
space). The call can also stop statistics 
collection. 

• MigrateOut(Which : process; Where- 
To: machine). This call enables the Starter 
(or its KernJob proxy if the Starter resides 
on another machine) to initiate migration. 

• MigrateIn(Which ; process; Where- 
From : machine; Accept: Boolean; Mem¬ 
ory : list of physical regions). The Starter 
or its KernJob proxy uses this call to ap¬ 
prove or refuse a migration from the given 
machine to the machine on which the call 
is performed. If Starters have negotiated 
among themselves, the Starter controlling 
the destination machine can approve a 


migration even before the Starter control¬ 
ling the source machine calls MigrateOut. 
The Memory parameter tells the kernel 
where in physical store to place the seg¬ 
ments that constitute the new process. (The 
Starter learns the segment sizes either from 
negotiation with its peer or from D’s re¬ 
quest to approve a migration offer received 
from S.) 

• CancelMigration(Which : process; 
Where: machine). The Starter invokes this 
call to abort an active Migrateln or Mi¬ 
grateOut request. This call is rejected if the 
migration has already reached a commit¬ 
ment point. 

None of these calls blocks the caller. 
The kernel reports the eventual success or 
failure of the request by a message back to 
the caller. 

Mechanism details. Three new modules 
in the kernel implement the migration 
mechanism. 

• The migration interface module deals 
with the new service calls from processes. 

• The migration protocol module per¬ 
forms the three phases listed above. 

• The statistics module collects and 
reports statistics. 

These modules are invoked by two new 
kernel threads. 

• The statistician thread awakens at each 
interval to sample, or average and report, 
statistics to the Starter. 

• A process-receiver thread starts in D 
for each incoming migrant process. It uses 
a simpler and faster communication proto¬ 
col than that used by ordinary IPC. How¬ 
ever, negotiation and other control mes¬ 
sages use the ordinary communication 
protocol and are funneled through the IPC 
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7: Accept offer 


Figure 2. Negotiation phase. 


queues to synchronize process and link 
activities. (The standard protocol must 
expect extremely complex scenarios that 
cannot arise in the transfer phase and must 
employ link data structures that are not 
germane here. The cost of introducing a 
streamlined protocol was slight in com¬ 
parison to the speed it achieved.) 

Figure 2 shows both high- and low-level 
negotiation messages. The left Starter 
controls machine 1, and its peer controls 
machine 3. The first two messages repre¬ 
sent a Starter-to-Starter negotiation that 
results in a decision to migrate process P 
from machine 1 to machine 3. The decision 
is communicated to S in message 3, which 
is either a direct service call (if the Starter 
runs on machine 1) or a message to the 
KernJob on machine 1 to be translated into 
a service call. 

S then offers to send the process to D. 
The offer includes P’s memory require¬ 
ments, its age, its recent CPU and network 
use, and information about its links. If D is 
short of the resources needed for P, or if too 


many migrations are in progress, it can 
reject the offer. Otherwise, D relays the 
offer to its controlling Starter (message 5). 
The relay includes the same information as 
the offer from S. We relay the offer to let 
the policy module reject a migrant at this 
point. Although D’s Starter might have 
agreed to accept P (in message 2), it might 
need to reject the offer now due to an actual 
or anticipated increase in load or lack of 
memory. Furthermore, D must ask its 
Starter because the kernel cannot know if 
the latter has even been consulted by its 
peer Starter, and the Starter must allocate 
memory for the migrant. 

The Starter’s decision is communicated 
to D by a Migrateln call (message 6). This 
call can also reject the migration offer (not 
shown). No relay occurs if the Starter has 
already called Migrateln to preapprove the 
migration. Before responding to S (mes¬ 
sage 7), D reserves necessary resources to 
avoid deadlock and flow-control prob¬ 
lems. Preallocation is conservative; it 
guarantees successful completion of mul¬ 
tiple migrations at the expense of reducing 


the number of concurrent incoming migra- 

D commits itself to the migration when 
it sends message 7. If P fails to arrive and 
S has not cancelled the migration (see the 
next step), then S’s machine must be down 
or unreachable. D discovers this condition 
through the standard mechanism by which 
kernels exchange “heart-beat” messages; 
it then reclaims resources and cleans up its 

When it receives message 7, S also 
commits itself to the migration and starts 
the transfer. Before each kernel commits 
itself, its Starter can successfully cancel 
the migration, in which case D replies 
Rejected to S (in message 7), or S sends 
Regretted to D (not shown). The latter also 
occurs if P dies abruptly during negotia¬ 
tion. To separate policy from mechanism, 
S does not retry a rejected migration unless 
so ordered by its Starter. 

Figure 3 shows the transfer phase. S 
concurrently sends P’s virtual space to D 
(message 8) and link update messages 
(message 9) to the kernels controlling all of 
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10: P’s context 


Figure 3. Transfer phase. 


P’s communication peers. Message 8 is 
broken into packets as required by the 
network. D has already reserved physical 
store for them, so the packets are copied 
directly to the correct place. Message 9 
indicates the new address of the link; it is 
acknowledged for synchronization pur¬ 
poses (not shown). After this point, mes¬ 
sages sent to P will be directed to the new 
address and buffered there until P is reat¬ 
tached. Kernels that have not yet received 
message 9 can still send messages for P to 
S. Failure of either the source or the desti¬ 
nation machine during this interval leaves 
P’s state very unclear. Since recovering 
P’s state would require a very complex 
protocol that would be sensitive to further 
machine failures, we opted to terminate P 
if one of the two machines crashes at this 
stage. 

Finally, S collects all of P’s context into 
a single message and sends it to D (mes¬ 
sage 10). This message includes control 
information, the state of all of P’s links, 
and details of communication requests that 
have arrived for P since transfer began. 
Pointers in S’s data structures are tracked 
down, and all relevant data are marshaled 
together. D demarshals the message into 
its own data structures. 

Although it is conceptually simple, the 
transfer stage is actually quite complex 


and time-consuming, mainly because 
Charlotte IPC is rich in context. Luckily, 
our design saves the migration mechanism 
from dealing with messages in transit to or 
from P. Since the kernel provides message 
caching but no buffering, 9 a message re¬ 
mains in its sender’s virtual address space 
until the receiver is ready to accept it or 
until the send is cancelled. Hence, S does 
not need to be concerned with P’s outgoing 
messages; likewise, it can drop from its 
cache any message received for P that P 
has not yet requested to receive. Such a 
message will be requested by D from the 
sender’s kernel when P requests to receive 
it. The link structures in message 9 clearly 
indicate which links have pending sent or 
received messages. Another advantage of 
our design is that we do not have to alter or 
transfer P’s context as maintained by dis¬ 
tributed utilities (such as open files, which 
are accessed via location-independent 
links). 

The establishment phase is interleaved 
with transfer. Data structures are deallo¬ 
cated as part of marshaling, and the re¬ 
served structures are filled during de¬ 
marshaling. After transfer, D adjusts P’s 
links and pending events and inserts P in 
the appropriate scheduling queue. Com¬ 
munication requests that were postponed 
while P was moving have been buffered by 


S and D; they are now directed to the IPC 
kernel thread in D in their order of arrival 
(for each link, all requests buffered at S 
precede those buffered at D). The effect of 
the messages on P is not influenced by the 
fact that P has moved. Finally, the Starter 
and KemJob processes for both the source 
and destination machines are informed that 
migration has completed so that they can 
update their data structures appropriately. 
A failure of either machine at the transfer 
phase is detected by the other machine, 
which aborts the migration, terminates the 
migrant, and cleans up its state. 

Performance. We measured Char¬ 
lotte’s migration performance on VAX/ 
11-750 machines connected by a Pronet 
token ring. The underlying mechanisms 
have the following costs: It takes 11 milli¬ 
seconds to send a 2-kilobyte packet to 
another machine reliably via the transport 
package we use, 0.4 millisecond to switch 
context between kernel and process, 10 
milliseconds to transfer a single packet 
between processes residing on the same 
machine, and 23 milliseconds to transfer a 
packet between processes residing on dif¬ 
ferent machines. 

The average elapsed time to migrate a 
small (32-kilobyte) linkless process is 242 
milliseconds (standard deviation 0 = 2 
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Table 2. Kernel time spent migrating a linkless 32-kilobyte process. 


S action 

Kernel time 

D action 

Kernel time 

Handle an offer 

5.0 

Handle an offer 

5.4 

Prepare 2-kilobyte 

2.6 

Install 2 kilobytes 

1.2 

image to transfer 


of image 


Marshal context 

1.8 

Demarshal context 

1.2 

Other (mostly kernel 

6.9 

Other 

4.7 

context switching) 





milliseconds), provided D’s Starter has 
preapproved the migration. Each addi¬ 
tional 2 kilobytes of image adds 12.2 milli¬ 
seconds to the migration time. The follow¬ 
ing formula fits our measurements of the 
average elapsed time spent in migration: 

Charlotte time = 

45 + 78p + 12.2s + 9.9r + Uq 

where p equals 0 if D’s Starter has preap¬ 
proved migration, 1 if D’s Starter is not on 
the destination machine, or about 0.2 
otherwise; s is the size of the virtual space 
in 2-kilobyte blocks; r equals 0 if all links 
are local, and 1 otherwise; and q is the 
number of nonlocal links (1 if none). 

These measures deviate by about five 
percent with different locations of the 
Starter and the overall load. This formula 
shows that it takes about 750 milliseconds 
to migrate a typical process of 100 kilo¬ 
bytes and six links (or 670 milliseconds if 
D’s Starter is local), and about 6 seconds 
for a large process of 1 megabyte. Actual 
CPU time spent on the migration effort for 
a 32-kilobyte process with no links is about 
60 milliseconds for S and about 32 milli¬ 
seconds for D. Table 2 shows how this time 
is spent. 

Each link costs S an additional 1.6-2.8 
milliseconds of CPU time to prepare link- 
update messages and marshal relevant data 
structures. Collecting statistics requires 
about one percent of the overall elapsed 
time, and another two percent is spent 
delivering the statistics to the Starter. A 
production version of Charlotte, optimized 
and stripped of debugging code, could 
exhibit a significant speed improvement. 

Comparing Charlotte’s migration per¬ 
formance with results published for other 
implementations is difficult because each 
uses a different underlying computer, and 
each operating system dictates its own 


process structure. Nonetheless, to provide 
some form of comparison, we present for¬ 
mulas for migration speed under Sprite 
(Sun-3 workstations, about four times 
faster than our VAX-11/750 machines), V 
(Sun-2 workstations, about two times 
faster than our machines), and Accent 
(Perq workstations, about 2.5 times slower 
than our machines). These formulas are 
extrapolations from a few measurement 
points reported elsewhere. 46 ’ 7 

Sprite time = 200 + 3.6s + 14/ 

V time = 80 + 6s 

Accent time = 1180 + 115s 

where s equals the size of the virtual space 
in kilobytes and / is the number of open 
files. In particular, a typical 100-kilobyte 
process would transfer in about 560 milli¬ 
seconds in Sprite, 680 milliseconds in V, 
and perhaps 12.7 seconds in Accent. To 
migrate a large, 1 -megabyte process would 
take at least 3.8 seconds in Sprite, 6 sec¬ 
onds in V, and 116 seconds in Accent. In 
Accent, sending the context of a process 
takes about one second. The virtual space 
is sent later on demand, so the full cost of 
transfer is spread over a long period, but 
part of this cost is saved if not all the pages 
are referenced. V precopies the address 
space while the process is still running, so 
the time lost by the process is quite short. 6 

Design issues 

The problem of designing a process 
migration facility encompasses such com¬ 
plex issues as the separation of policy and 
mechanism, the interplay between migra¬ 
tion and other mechanisms, reliability, 
concurrency, the nature of context trans¬ 
fer, and the extent to which processes 
should be independent of their location. 


These issues interrelate, so the following 
discussion will occasionally postpone de¬ 
tails until later sections. Moreover, the 
approaches that we and others take to vari¬ 
ous problems depend somewhat on the 
design of other components of the operat¬ 
ing system. Due to space limitations, we do 
not discuss these dependencies in detail. 

Structure. The first step in designing a 
process migration facility is deciding 
where the policy-making and mechanism 
modules should reside. This decision is 
of major importance, since it cannot be 
easily reversed, unlike most of the migra¬ 
tion protocol’s design. Communication- 
kernel operating systems tend to put 
mechanisms in the kernel and policy in 
trusted utility processes. In the case of 
process migration, mechanism is inter¬ 
twined with both short-term scheduling 
and IPC, so it fits best in the kernel. Policy, 
on the other hand, is associated with long¬ 
term scheduling and resource manage¬ 
ment, so it fits well in a utility process. 
Several considerations affect the success 
of separation, including the efficiency of 
the result, how adequately it provides 
the needed function, and the degree of con¬ 
ceptual simplicity of the interfaces and the 
implementation. 

Efficiency and simplicity. The principal 
reason one might place policy in the kernel 
instead of in a utility is to simplify and 
speed up the interface between policy and 
mechanism. Any reasonable policy de¬ 
pends on statistics that are maintained 
primarily in the kernel. High-quality deci¬ 
sions could require large amounts of accu¬ 
rate and comprehensive data. Placing pol¬ 
icy outside the kernel incurs execution 
overhead and latency in passing statistics 
in one direction and decisions in the other. 

Our experience with Charlotte, how¬ 
ever, shows that placing the policy in a 
utility results in a net efficiency gain. Al¬ 
though separation incurs the extra cost of 
one message for statistics reporting and 
one kernel call (and perhaps another mes¬ 
sage round-trip) for decision reporting, it 
allows reduction of communication and 
more-global policy, since each Starter 
process decides policy for a set of ma¬ 
chines. Also, concerning the latency in 
passing statistics and decisions, it is likely 
that good policies depend mostly on aggre¬ 
gate and medium-term conditions, ignor¬ 
ing short-term conditions or small delays. 

A designer who chooses to support only 
simple policies might well put them in the 
kernel. For example, the migration policy 
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in V 6 and Sprite 4 is mostly manual, choos¬ 
ing a remote idle workstation for a process 
or evicting it when the station’s owner so 
requires. In systems where migration is 
used to meet real-time scheduling dead¬ 
lines, policy tends to be simple or very 
sensitive to even small delays, and hence 
could (or should) be placed in the kernel. 
Integrating the policy in the kernel, how¬ 
ever, might obstruct later expansion or 
generalization. 

We can achieve conceptual separation 
of policy and mechanism without incur¬ 
ring a large interface cost by assigning 
them to separate layers that share memory. 
MOS adopts this approach by dividing the 
kernel into two layers: one to implement 
migration mechanism and other low-level 
functions, and the other to provide policy. 2 
These layers share data structures and 
communicate by procedure calls. Such 
sharing improves efficiency but makes it 
harder to modify policy, since changes 
require kernel recompilation, and inadver¬ 
tent errors become more serious. 

Function and flexibility. Placing policy 
outside the kernel facilitates testing di¬ 
verse policies and choosing among poli¬ 
cies designed for different goals, such as 
load sharing, load balancing, improving 
responsiveness, reducing the communica¬ 
tion load, and placing processes close to 
special devices. The ability to modify pol¬ 
icy is especially important in an experi¬ 
mental environment. Our students needed 
only a few hours to learn the interface and 
major components of the Starter to begin 
trying different policies; they did not need 
to learn peculiarities of the kernel or of the 
migration mechanism. This flexibility 
would have been impossible if policy were 
embedded in the kernel. 

In distributed systems such as Demos/ 
MP, 5 Accent, 12 and Charlotte, resource- 
management policies are often relegated to 
utilities. Putting migration policy in those 
same processes can allow more integration 
and coordination of the policies governing 
the system. 

The designer of process migration 
should be aware of the danger of separat¬ 
ing policy and mechanism too far. Letting 
policy escape from trusted utility servers 
into application programs can result in 
performance degradation or even thrash¬ 
ing. This problem occurs, for example, 
when applications can decide the initial 
placement and later relocation of their 
processes, as in Locus, 3 without assistance 
from the kernel in the form of timely state 
and load information. 


Rescuing migrating 
processes under all failure 
circumstances requires 
complex recovery 
protocols 
and, most likely, 
large overhead. 


Interplay between migration and other 
mechanisms. The process-migration 
mechanism can be designed independently 
of other mechanisms, such as IPC and 
memory management. The actual implem¬ 
entation is likely to have interactions 
among these mechanisms. However, de¬ 
sign separation means that the migration 
protocol should not change when the IPC 
protocol does. In Charlotte, for example, 
we did not change the IPC to add process 
migration, nor did migration change when 
we later modified the semantics of two IPC 
primitives. In contrast, we had to change 
the marshaling routines when an IPC data 
structure changed. 

We feel that ease of implementation is a 
dominant motivation for separating 
mechanisms when adding process migra¬ 
tion to an existing operating system, as was 
the case in Demos/MP, Charlotte, V, and 
Accent. A secondary motivation is that the 
migration code can be deactivated without 
interfering with other parts of the kernel. In 
Charlotte, for instance, we can easily 
remove all the code and structures of pro¬ 
cess migration at compile time or dynami¬ 
cally turn the mechanism on and off. 

In contrast, efficiency arguments favor 
integrating all mechanisms. Accent, for 
example, uses a transfer-on-reference 
approach to transmitting the virtual space 
of the migrant process, based on its copy- 
on-write memory management. 7 If process 
migration is intended from the start, as in 
MOS and Sprite, integration can reduce 
redundancy of mechanisms. In retrospect, 
we would have used a different IPC im¬ 
plementation for Charlotte if the two 
mechanisms had been integrated from the 
start. We would have used hints for link 
addresses, which are inaccurate but can be 
readily checked and inexpensively main¬ 
tained, rather than using absolutes, whose 
complete accuracy is achieved at a high 
maintenance cost. 


Some interactions seem to be necessary. 
In Charlotte, for instance, we chose to 
simplify the migration protocol by refus¬ 
ing to migrate a process engaged in multi¬ 
packet message transfer. We therefore 
depend slightly on knowledge of the IPC 
mechanism to avoid complex protocols. 
Similarly, both MOS and Sprite refuse to 
migrate a process engaged in a remote 
procedure call until it reaches a convenient 
point, which might not happen for a long 
time. Other interactions make sense for 
process migration to take advantage of 
existing facilities. For example. Locus 
uses existing process-creation code to as¬ 
sist in process migration. 

Reliability. Migration failures can oc¬ 
cur due to network or machine failure. The 
migration mechanism can simply ignore 
these possibilities (as does Demos/MP) to 
streamline protocols. The Charlotte im¬ 
plementation can rescue the migrant from 
many failures by several means. First, it 
transfers responsibility for the migrant as 
late as possible to survive failure of the 
destination or the network. Second, it de¬ 
taches the migrant completely from its 
source to survive later failures of the 
source. Third, the migrant is protected 
from failures of other machines; at worst, 
some of its links are automatically de¬ 
stroyed if the machine where their other 
ends reside crashes. 

Rescuing migrating processes under all 
failure circumstances requires complex 
recovery protocols and, most likely, large 
overhead for maintaining process replicas, 
checkpoints, or communication logs. We 
were unwilling to pay that cost in Char¬ 
lotte. Instead, we terminate the migrant if 
either the source or destination machine 
crashes during the sensitive time of trans¬ 
fer when messages for the migrant might 
have arrived at either machine, as dis¬ 
cussed earlier. Modifying our IPC to use 
hints for link addresses, as mentioned 
above, would have made this step less 
fragile. 

Concurrency. Various levels of con¬ 
currency are conceivable: 

• only one migration in the network at a 
time; 

• only one migration affecting a given 
machine at a time; or 

• no constraints on the number of simul¬ 
taneous migrations. 

The Charlotte mechanism puts no con¬ 
straint on concurrency. Restricting process 
migration can make the mechanism sim- 
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pier, especially in operating systems using 
a connection-based IPC. The most restric¬ 
tive alternative guarantees that the peers of 
the migrant process are stationary, so redi¬ 
rection of messages is straightforward. It 
also tends to mitigate policy problems of 
migration thrashing, flooding a lightly 
loaded machine with immigrants, and 
completely emptying a loaded machine. 

Enforcing such a constraint, on the other 
hand, requires contention arbitration, 
which can be expensive. In addition, limit¬ 
ing concurrency constrains policies that 
otherwise could evacuate a failing ma¬ 
chine quickly or react immediately to a 
severe load imbalance. We therefore be¬ 
lieve that the policy problems mentioned 
above should be solved by policy algo¬ 
rithms, not by a limitation imposed by the 
mechanism. 

Allowing simultaneous migrations in¬ 
troduces the peculiar problem of name and 
address consistency: ensuring that all pro¬ 
cesses and kernels have a consistent view 
of the world. The problem is manifest in 
operating systems like Charlotte, in which 
communication is carried out over estab¬ 
lished channels and kernels require up-to- 
date location information. If two processes 
connected by a channel migrate at the same 
time, their kernels might have a false con¬ 
ception of the remote channel ends. 

The problem is not critical in operating 
systems such as V that treat communica¬ 
tion addresses as hints because communi¬ 
cation that encounters a hint fault will 
restore the hint by invoking a process¬ 
finding algorithm. This solution incurs 
execution and latency costs as messages 
are transmitted. Where absolutes are used, 
forwarding pointers, such as those used in 
Demos/MP, can solve the problem, but 
they introduce long-lived residual depend¬ 
encies. In Charlotte, we send link-address 
updates before migration completes, and 
we buffer notifications for messages arriv¬ 
ing during the transfer. The immediate 
acknowledgment of the updates, even 
when the other link end is simultaneously 
given away or migrating, prevents dead¬ 
lock. When migration completes, D pro¬ 
cesses the notifications buffered by the 
two kernels and regains a consistent view 
of P’s links, even if their remote ends have 
moved in the meantime. 

Within a single source or destination, we 
could restrict concurrency to one migra¬ 
tion attempt at a time. This restriction 
simplifies the kernel state and again re¬ 
duces the risk of thrashing. However, we 
reduce complexity by creating a new ker¬ 
nel thread for each migration in progress. 


Resorting to a home 
machine makes 
communication failures 
more likely and 
sharply increases the 
cost of certain 
kernel calls. 


executing a finite-state protocol independ¬ 
ently of other migration efforts. Using 
these techniques, we found that allowing 
concurrent migrations in the same machine 
incurs only a small space overhead and 
minor execution costs. 

Context transfer and residual 
dependency. The migrating process must 
be frozen at some point to ensure a consis¬ 
tent transfer. 

What and when to freeze. Three activi¬ 
ties need to be frozen: process execution, 
outgoing communication, and incoming 
communication. The first two activities 
are trivial to freeze. Incoming communica¬ 
tion can be frozen by 

• telling all peers to stop sending, 

• delaying incoming messages, or 

• rejecting incoming messages. 

The first option requires a complex proto¬ 
col if concurrent migrations are supported 
or if crashes must be tolerated. The third 
option requires that the IPC be able to 
resend rejected messages, as in V. We 
chose the second option because it seems 
the simplest and does not interfere with 
other mechanisms. 

Very early freezing of the process (for 
example, when it is considered as a migra¬ 
tion candidate) has the advantage that the 
process does not change state between the 
decision and migration. Otherwise, the 
migration decision might be worthless, 
since the process could terminate or start 
using resources differently. However, 
freezing a process hurts its response time, 
which flies in the face of one of the goals of 
migration. Less conservatively, we can 
freeze a process when it is selected as a 
candidate but before the destination ma¬ 
chine has accepted the offer. Even less- 
conservative alternatives include freezing 


when migration is agreed on or only when 
it is completed. As the choices become less 
conservative they increase the process’ 
responsiveness at the cost of protocol 
complexity. 

We chose to balance responsiveness and 
protocol simplicity by freezing both exe¬ 
cution and communication only when 
context is marshaled and transferred. We 
delay incoming communication until P is 
established by buffering input notifica¬ 
tions at S and D. We verified (by exhaus¬ 
tive enumeration of states in our automata 
that drive the IPC protocol) that the ensu¬ 
ing delays could not cause deadlock or 
flow-control problems." In this way, a 
minimal context is transferred during ne¬ 
gotiation (such as how many links P has 
and where their ends are); the final transfer 
reflects any change in P’s state during 
migration. 

MOS and Locus freeze the migrant ear¬ 
lier, when it is selected for migration. V, in 
contrast, freezes a process for a minuscule 
interval near the end of transfer. The mi¬ 
grant continues to execute during the trans¬ 
fer; pages dirtied during this episode are 
sent again in another transfer pass, and so 
forth until a final pass. Incoming messages 
are rejected during the short freeze, with 
the understanding that the IPC mechanism 
will time out and retransmit them. The 
result is that the migrant suffers a delay 
comparable to that required to load a pro¬ 
cess into memory. 6 

Redirecting communication. Redirect¬ 
ing communication requires that state in¬ 
formation relevant to the communication 
channels be updated and that peer kernels 
discover the migrant’s new location. In a 
connectionless IPC mechanism, a process 
holds the names of its communication 
peers. For example, V processes use pro¬ 
cess identifiers as destinations. 13 A kernel 
can then broadcast the new location, but 
this can be expensive for large networks 
with frequent migrations. Alternatively, 
peers can be left with incorrect data that 
can be resolved on hint faults. Another 
alternative assigns a home machine to each 
process; the home machine always knows 
where the process is. Locus uses this 
method to find a signal’s target. Sprite is 
similar; the home machine manages sig¬ 
nals and other location-dependent 
operations on behalf of the migrant. Of 
course, resorting to a home machine makes 
communication failures more likely and 
sharply increases the cost of certain kernel 
calls. 

In a connection-based IPC environment 
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with simplex connections, such as Accent 
and Demos/MP, the kernel of a connec¬ 
tion’s receiving end does not know where 
the senders are. Thus, S does not know 
which kernels to inform about P’s migra¬ 
tion. Instead, a forwarding pointer can be 
left on S to redirect new messages as they 
arrive. Demos/MP uses this strategy. 
Another approach introduces a stationary 
“middleman” between two or more mobile 
ends of a connection. In Locus, cross¬ 
machine pipes can have several readers 
and writers, but they have only one fixed 
storage site. When a reader or writer mi¬ 
grates, the kernel managing the storage site 
is informed. In Charlotte, the duplex na¬ 
ture of links suggests maintaining infor¬ 
mation at each end about the other, so S can 
tell all of P’s communication peers that P 
has moved. Transferring these link data 
along with P, though, incurs marshaling, 
transmission, and demarshaling overhead. 

Residual dependency. The migrant pro¬ 
cess can start working on the destination 
machine faster if it temporarily leaves 
some of its state on the source machine. 
When it needs to refer to that state, it can 
access it with some penalty. To reduce the 
penalty, state can be gradually transferred 
during idle moments. State can also be 
pulled on demand. The choice between 
moving all or only a part of the address 
space is reminiscent of the controversy in 
network file systems about whether entire 
files or only pages should be transferred 
for remote file access. Locality of execu¬ 
tion suggests transferring at least the work¬ 
ing set of P during migration and the rest 
when needed. On the other hand, the objec¬ 
tive of residual independence suggests 
removing any trace of P from the source 
machine. 

In MOS, virtually the entire state of P 
could remain in the source machine, since 
D can make remote calls on S for anything 
it needs. For efficiency reasons, however, 
MOS transfers most of P’s context and 
state when it migrates. In Sprite, part of P’s 
context always resides in its home ma¬ 
chine, but none is left on the source ma¬ 
chine when P is evicted. This approach 
costs about 15 milliseconds to demand¬ 
load a page and perhaps 4 milliseconds to 
execute some of the kernel calls remotely 
(about a ninefold increase). In Accent, 
processes do not make kernel calls di¬ 
rectly; rather, they send messages to a 
kernel port. Therefore, no state needs to 
move with a process; it can all remain with 
S and be accessed as needed by kernel calls 
to the old port. In addition, Accent imple- 


Separating the modules 
that implement 
mechanism from those 
responsible for policy 
allows more efficient 
and flexible policies and 
simplifies the design. 


ments a lazy transfer of data pages on 
demand. Similarly, in Sprite, S acts as a 
paging device for D. These approaches 
trade efficiency of address-space transfer 
for risks of machine unavailability, proto¬ 
col complexity, and later access penalties. 

Location transparency. Many distrib¬ 
uted operating systems adhere to the prin¬ 
ciple of location transparency. In particu¬ 
lar, process names are independent of their 
location, processes can request identical 
kernel services Wherever they reside, and 
they can communicate with their peers 
equally well (except for speed) wherever 
they might be. 

The principle of location transparency 
must be followed carefully to enable mi¬ 
gration. Migration requires that naming 
schemes be uniform for local and remote 
communication and that resource refer¬ 
ences not depend on the host machine. For 
example, Charlotte objects are named by 
the links that connect a client to them. 
When a process moves, its names for the 
links are unchanged, even though D re¬ 
maps them to different internal names. 

The fact that local communication is 
treated differently from remote communi¬ 
cation is localized in a few places in the 
kernel. Processes might have pointers or 
indices to kernel data structures, but those 
are maintained by the kernel. The actual 
data structures, pointers, and indices are 
remapped invisibly during migration. If 
such values were buried inside the pro¬ 
cesses’ address spaces, migration would 
be impossible or extremely complicated. 
Sprite maintains location transparency 
throughout multiple migrations by keep¬ 
ing location-dependent information on P’s 
home machine and by directing some of 
P’s kernel calls there. 

Transaction management and multi¬ 
threading also pose transparency prob¬ 
lems. A transaction manager must not 


depend on the location of its clients. Multi¬ 
threaded processes must be moved in toto. 
If threads can cross address spaces, the 
identity of one thread might be recorded in 
several address spaces, leading to location 
dependencies. 

Of course, any policy setter, such as the 
Charlotte Starter, needs to know the loca¬ 
tion of all processes and perhaps the end¬ 
points of their heavily used links. Making 
this information available need not com¬ 
promise the principle of transparency. The 
policy module does not use this informa¬ 
tion to send messages, only to inform itself 
about decisions it needs to make. Like¬ 
wise, for the sake of openness, a design 
might allow processes willing to partici¬ 
pate in migration decisions to receive loca¬ 
tion information and contribute migration 
advice. 


O ur experience with Charlotte and 
others’ experience with Sprite, 
V, MOS, and Demos/MP show 
that process migration is possible, if not al¬ 
ways pleasant. We found that separating 
the modules that implement mechanism 
from those responsible for policy allows 
more efficient and flexible policies and 
simplifies the design. Migration interacts 
with other parts of the kernel. In particular, 
the implementation shares structures and 
low-level functions with other mecha¬ 
nisms. Nonetheless, we found it possible to 
keep the mechanisms fairly independent of 
each other, gaining high code modularity 
and ease of maintenance. 

Software and hardware failures are a 
fact of life. Our migration protocol can 
rescue the migrant in most failure situ¬ 
ations and restore the state in all of them, 
despite the fact that the migrant continues 
its interaction with other processes at early 
stages of migration. In some cases, though, 
we opt to kill the migrant even if rescue is 
dimly conceivable. We postpone commit¬ 
ting migration until the transfer itself (to 
deal with early destination crash), while 
removing any dependency of the migrant 
on the source as soon as migration com¬ 
pletes (to deal with late source crash). 

Except for potential confusion suffered 
by policy modules, it is not particularly 
hard to achieve simultaneous migrations, 
even those involving a single machine. 
The Charlotte IPC requires absolute state 
information, so we could not reduce the 
cost of migration by sacrificing accuracy. 
IPC mechanisms that use hints or are con¬ 
nectionless can shorten the elapsed time 


September 1989 


55 







for migration but then probably pay more 
during communication. Designs that re¬ 
quire previous hosts to retain forwarding 
information for an arbitrary period after 
migration are overly susceptible to 
machine failure. Forwarding data struc¬ 
tures, although small, tend to build up over 
time. □ 
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A Master of Software 
Engineering Curriculum 

Recommendations from the 
Software Engineering Institute 


Gary A. Ford and Norman E. Gibbs 
Carnegie Mellon University 


I ndustry is concerned that colleges and 
universities are not producing stu¬ 
dents who can work productively on 
industrial software projects. Recent gradu¬ 
ates understand coding, compilers, operat¬ 
ing systems, and Turing machines but not 
working in teams under real constraints. 
Somewhat oversimplified, industry needs 
software engineers, but universities are 
supplying computer scientists. Thus, it’s 
time to promote widespread development 
of software engineering degree programs. 

The United States Department of De¬ 
fense recognized the importance of soft¬ 
ware engineering education when it estab¬ 
lished the Software Engineering Institute 
at Carnegie Mellon University in Decem¬ 
ber 1984. Part of the SEI’s mission is to 
influence software engineering curricula 
development, and the SEI Education Pro¬ 
gram has been pursuing this mission for 
nearly five years. 1 

There is anything but consensus on what 
software engineering education should 
encompass, so we find ourselves in the 
same situation as the developers of com¬ 
puter science curricula in the 1960s. John 
Hopcroft, in his 1986 ACM Turing Award 
Lecture, 2 recalled his experience at Prince¬ 
ton University in the fall of 1964: 

Princeton asked me to develop a course in 
automata theory to expand the scope of the 
curriculum beyond the digital circuit design 
course then being offered. Since there were 
no courses or books on the subject, I asked 
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The SEI is promoting 
software engineering 
curricula 
development 
throughout the 
academic community. 
This report presents 
an organizational 
structure for content 
and a model 
curriculum for an 
MSE degree. 


[Edward] McCluskey to recommend some 
materials for a course on automata theory. 
He was not sure himself, but he gave me a list 
of six papers and told me that the material 
would probably give students a good back¬ 
ground in automata theory. . . . 

At the time, I thought it strange that indi¬ 
viduals were prepared to introduce courses 
into the curriculum without clearly under¬ 
standing their content. In retrospect, I realize 
that people who believe in the future of a 
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subject and who sense its importance will 
invest in the subject long before they can 
delineate its boundaries. 

Likewise, we cannot delineate bound¬ 
aries for many of the courses we 
recommend. We do believe, however, in 
teaching them now and sharing 
experiences. This will be valuable to 
today’s students and lead to improved 
courses for tomorrow’s students. 

In this report, we present a structure of 
the software engineering discipline as a 
first step toward identifying its content and 
boundaries. We then recommend a core 
master’s-level curriculum in software 
engineering. 

Mapping the structure 
of software engineering 

The body of knowledge called software 
engineering consists of many interrelated 
topics. This knowledge cannot be captured 
as an undifferentiated mass; it needs an 
organizational structure. The structure we 
describe below is not a taxonomy of soft¬ 
ware engineering; rather, it is a guide for 
collecting and documenting software engi¬ 
neering knowledge and practice and for 
describing recommended course content. 

The software engineering discipline is 
frequently described in terms of a software 
life cycle: requirements analysis, specifi¬ 
cation, design, implementation, testing, 
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and maintenance. These life-cycle phases 
are worth presenting, but their one-dimen¬ 
sional structure is inadequate for organiz¬ 
ing all software engineering topics and 
describing the curriculum. 

A good course, whether a semester 
course in a university or a one-day short 
course in industry, must have a central 
thread or idea, but not every course can or 
should focus on one life-cycle phase. 
Engineering courses (including software 
engineering) can look at either engineering 
processes or the resulting products. We 
have chosen these two views as the highest 
level for partitioning curriculum content. 

Process view. The process of software 
engineering includes a broad range of ac¬ 
tivities performed by software engineers, 
but across the range, many aspects of each 
activity are similar. Thus, we’ve organized 
the process topics into two dimensions: 
activity and aspect. 

Activity dimension. Process activities 
divide into four groups: development, 
control, management, and operations. 

Development activities create or pro¬ 
duce the software system’s artifacts, in¬ 
cluding requirements analysis, specifica¬ 
tion, design, implementation, and testing. 
Because a software system is usually part 
of a larger system, we sometimes distin¬ 
guish system activities from software ac¬ 
tivities — for example, system design from 
software design. Many large projects will 
have both systems engineers and software 
engineers; nevertheless, because software 
engineers need an appreciation of the proj¬ 
ect’s systems aspects, these aspects should 
be included in a curriculum. 

Control activities restrain, constrain, or 
direct software development. These activi¬ 
ties are more concerned with controlling 
how development activities are done than 
with artifact production. Of the two major 
control activities, one relates to software 
evolution and the other to software quality. 

A software product evolves in the sense 
that it exists in many different forms as it 
moves through its life cycle, from initial 
concept through development and use to 
eventual retirement. Change control and 
configuration management are activities 
related to evolution. We also consider 
software maintenance in this category, 
rather than as a separate development ac¬ 
tivity, because the difference between 
development and maintenance is not in the 
activities performed (both involve require¬ 
ments analysis, specification, design, 
implementation, and testing) but in the 


way those activities are constrained and 
controlled. For example, the fundamental 
constraint in software maintenance is the 
preexistence of a software system coupled 
with the belief that it is more cost-effective 
to modify that system than to build a new 
one. Software quality activities include 
quality assurance, test and evaluation, and 
independent verification and validation. 
These activities, in turn, incorporate such 
tasks as software technical reviews and 
performance evaluation. 

Management activities involve the ex¬ 
ecutive, administrative, and supervisory 
direction of a software project, including 
technical activities that support the execu¬ 
tive decision process. Typical manage¬ 
ment activities are project planning 
(scheduling, establishing milestones), re¬ 
source allocation (staffing, budgeting), 
development team organization, cost esti¬ 
mation, and legal aspects (contracting, 
licensing). These activities are an appro¬ 
priate part of a software engineering cur¬ 
riculum for several reasons: (1) the body of 
knowledge about managing software proj¬ 
ects is different from that about managing 
other kinds of projects; (2) many software 
engineers assume software management 
positions at some point in their careers; and 
(3) knowledge of this material by all soft¬ 
ware engineers improves teamwork on 
large projects. 

Operations activities relate to an organi¬ 
zation’s use of a software system. These 
activities include training personnel in 
system use, planning for system delivery 
and installation, changing from the old 
(manual or automated) system to the new 
one, operating the software, and retiring 
the system. Software engineers seldom 
have primary responsibility for these ac¬ 
tivities, but often participate on teams that 
do. They also need to be aware of the 
impact these activities have on system 
development decisions. 

Operation of software engineering sup¬ 
port tools provides a case of special inter¬ 
est. These tools are software systems used 
by the software engineers themselves. 
Operations activities for these systems can 
be observed and experienced directly. An 
awareness of the issues related to their use 
can not only help software engineers de¬ 
velop systems for others, but also help 
them adopt and use new tools for their own 
activities. 

Aspect dimension. Engineering activi¬ 
ties are traditionally partitioned into ana¬ 
lytic activities and synthetic activities. We 
chose instead an orthogonal axis that 


somewhat captures this distinction but 
recognizes six aspects of these activities: 
abstractions, representations, methods, 
tools, assessment, and communication. 

Abstractions include fundamental prin¬ 
ciples and formal models. For example, 
software development process models 
(waterfall, iterative enhancement, etc.) are 
models of software evolution. Finite state 
machines and Petri nets are models of 
sequential and concurrent computation, 
respectively. Cocomo is a software cost- 
estimation model. Modularity and infor¬ 
mation hiding are principles of software 
design. 

Representations include notations and 
languages. The Ada,programming lan¬ 
guage thus fits into the organization as an 
implementation language, while decision 
tables and dataflow diagrams are design 
notations. PERT charts are a notation use¬ 
ful in project planning. 

Methods include formal methods, cur¬ 
rent practices, and methodologies. Proofs 
of correctness are examples of formal 
methods for verification. Object-oriented 
design is a design method, and structured 
programming may be considered a current 
implementation practice. 

Tools include individual software tools 
as well as integrated tool sets (and, implic¬ 
itly, the hardware systems on which they 
run). Examples include general-purpose 
tools, such as electronic mail and word 
processing, tools related to design and 
implementation, such as compilers and 
syntax-directed editors, and project man¬ 
agement tools. Other kinds of software 
support for process activities are also in¬ 
cluded; these are sometimes described by 
such terms as infrastructure, scaffolding, 
or harnesses. 

Sometimes the term “environment” is 
used to describe a set of tools, but we prefer 
to reserve this term to mean a collection of 
related representations, tools, methods, 
and objects. Software objects are abstract, 
so we can only manipulate their represen¬ 
tations. Manipulation tools are usually 
designed to help automate a particular 
method or way of accomplishing a task. 
Typical tasks involve many objects (code 
modules, requirements specification, test 
data sets, etc.), so those objects must be 
available to the tools. Thus, we believe all 
four parts are necessary for an environ- 

Assessment aspects include measure¬ 
ment, analysis, and evaluation of software 
products and software processes and the 
impact of software on organizations; met¬ 
rics and standards are also placed in this 
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2. Object-oriented design 

3. Cocomo model 

4. Path coverage testing 

5. Interactive video 


6. Performance evaluation 

7. Configuration management plan 

8. Waterfall model 

9. Code inspection 

10. PERT chart 


Development 

(requirements analysis, specification, 
design, implementation, testing, ...) 


Control 

(quality assurance, configuration 
management, independent V&V,...) 


Management 

(project planning, resource allocation, 
cost estimation, contracting,...) 


Operations 

(training, system transition, operation, 
retirement,...) 


Figure 1. The process view: examples of activities and aspects. 


category. This area deserves considerable 
emphasis in the curriculum, since software 
engineers, like engineers in the traditional 
fields, need to know what to measure, how 
to measure it, and how to use the results to 
analyze, evaluate, and ultimately improve 
processes and products. 

Communication is the final aspect. All 
software engineering activities include 
written and oral communication, and most 
produce documentation. A software engi¬ 
neer must have good general technical 
communication skills, as well as an under¬ 
standing of appropriate forms of documen¬ 
tation for each activity. 

Considering the activity and aspect 
dimensions as orthogonal produces a ma¬ 
trix of ideas that might serve as the central 
thread in a course (Figure 1). Individual 
matrix cells most likely represent topics 
too specialized for a full semester course. 
We recommend designing courses around 
part or all of a horizontal or vertical slice 
through the matrix. 


Product view. It is often appropriate to 
discuss activities and aspects in the context 
of a particular kind of software system. For 
example, concurrent programming has 
notations for specification, design, and 
implementation not needed in sequential 
programming. Instead of inserting a seg¬ 
ment on concurrent programming into 
several courses, it is probably better to 
gather all the appropriate information into 
one course. A similar argument can be 
made for information related to various 
system requirements; for example, achiev¬ 
ing system robustness involves aspects of 
requirements definition, specification, 
design, and testing. 

Therefore, we added two categories to 
the curriculum content organizational 
structure: software system classes and 
pervasive system requirements. Although 
these may be viewed as dimensions or¬ 
thogonal to the activity and aspect dimen¬ 
sions, every point in the resulting four¬ 
dimensional space does not necessarily 


represent a topic for which there is a body 
of knowledge or for which a course should 
be taught. Figure 2 shows an example of a 
point for which there is a very small but 
nonempty body of knowledge. 

Any of the system classes or pervasive 
requirements described below might be the 
central thread in a software engineering 
course, but the material might also be 
taught in a course whose central thread is 
one of the activities mentioned earlier. For 
example, techniques for designing real¬ 
time systems could be taught in a design 
course or in a real-time systems course. 
Testing methods to achieve system robust¬ 
ness could be taught in a testing course or 
in a robustness course. The purpose of 
adding these two new dimensions to the 
structure is to allow better descriptions of 
possible courses. 

Software system classes. Of the differ¬ 
ent classes that can be considered, one 
group is defined in terms of a system’s 
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relationship to its environment and has 
members described by terms such as batch, 
interactive, reactive, real time, and embed¬ 
ded. Another group has members de¬ 
scribed by terms such as distributed, con¬ 
current, or network. Another is defined in 
terms of internal characteristics, such as 
table-driven, process-driven, or knowl¬ 
edge-based. We also include generic or 
specific applications areas, such as avion¬ 
ics systems, communications systems, 
operating systems, or database systems. 

Clearly, these classes are not disjoint. 
Each class is composed of members that 
have certain common characteristics, and 
there may be a body of knowledge directly 
addressing the development of systems 
with those characteristics. Thus, each class 
may be the central theme in a software 
engineering course. 

Pervasive system requirements. Al¬ 
though discussions of system requirements 
generally focus on functional require¬ 
ments, other categories deserve attention. 
Identifying and meeting those require¬ 
ments is the result of activities performed 
throughout the software engineering pro¬ 
cess. As with system classes, it may be 
appropriate to choose one of these require¬ 
ment categories as the central thread for a 
course and then to examine those activities 
and aspects that affect it. 

Examples of pervasive system require¬ 


ments are accessibility, adaptability, 
availability, compatibility, correctness, 
efficiency, fault tolerance, integrity, inter¬ 
operability, maintainability, performance, 
portability, protection, reliability, reusa¬ 
bility, robustness, safety, security, testa¬ 
bility, and usability. Definitions of these 
terms appear in the IEEE Standard Glos¬ 
sary of Software Engineering Terminol¬ 
ogy. 3 

MSE curriculum 

The academic community distinguishes 
two master’s-level technical degrees. The 
master of science in <discipline>, a re¬ 
search-oriented degree, often requires a 
thesis and leads to doctoral-level study. 
The master of <discipline>, a terminal 
professional degree, requires a project or 
practicum to demonstrate the level of 
knowledge acquired and should produce a 
practitioner who can rapidly assume a 
position of substantial responsibility. The 
master of business administration (MBA) 
degree is perhaps the most widely recog¬ 
nized example of a professional degree. 

The SEI was chartered partly in response 
to the perceived need for many more, 
highly skilled software engineers. We be¬ 
lieve this need can be best addressed by 
encouraging and helping academic institu¬ 
tions offer a master of software engineer¬ 


ing (MSE) degree program. 

We use a broad view of software engi¬ 
neering in choosing curriculum content, 
and we include several topics that are not 
part of a typical engineering curriculum. 
This statement of the National Research 
Council about engineering curricula re¬ 
flects the views of many engineers and 
educators 4 : 

Another element of the problem is that to 
make the transition from high school gradu¬ 
ate to a competent practicing engineer re¬ 
quires more than just the acquisition of tech¬ 
nical skills and knowledge. It also requires a 
complex set of communication, group-inter¬ 
action, management, and work-orientation 

. . . For example, education for manage¬ 
ment of the engineering function (as distinct 
from MBA-style management) is notably 
lacking in most curricula. Essential nontech¬ 
nical skills such as written and oral commu¬ 
nication, planning, and technical project 
management (including management of the 
individual’s own work and career) are not 
sufficiently emphasized. 

On the other hand, we have narrowed the 
curriculum by concentrating almost exclu¬ 
sively on software engineering (but in¬ 
cluding some aspects of systems engineer¬ 
ing) and omitting applications-area knowl¬ 
edge. Two major reasons for this are prag¬ 
matic: first, the body of knowledge known 
as software engineering is large enough to 
require all the available time in a typical 
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master’s degree program (and then some), 
and second, students cannot study all the 
applications areas in which they might 
eventually work. We also believe that a 
graduate-level student should have the 
self-education skills to acquire applica¬ 
tion-area knowledge. 

More importantly, however, the variety 
of application areas and the level of sophis¬ 
tication of their hardware and software 
systems mandate a substantial range of 
knowledge and skills among development 
team members. Some team members must 
understand the capabilities of a system’s 
hardware and software components to do 
the highest level specification, while other 
members must have the skills to design and 
develop individual components. Software 
engineers will have responsibility for soft¬ 
ware components, just as electrical, me¬ 
chanical, or aeronautical engineers, for 
example, will have responsibility for hard¬ 
ware components. Scientists, including 
computer scientists, will often be needed 


on development teams, and all the scien¬ 
tists and engineers must be able to work 
together toward a common goal. 

The following sections outline an MSE 
program in terms of objectives, prerequi¬ 
sites, curriculum content, project experi¬ 
ence, and course structure. A more detailed 
description of the program is available 
from the SEI. 5 

Objectives. The overall objective of the 
MSE degree is to produce a software engi¬ 
neer who can rapidly assume a position of 
substantial responsibility within an organi¬ 
zation. To achieve this objective, we pro¬ 
pose a curriculum designed to give the 
student a body of knowledge — including 
balanced coverage of software engineer¬ 
ing process activities, their aspects, and the 
products they produce — and sufficient 
experience to bridge the gap between 
undergraduate programming and profes¬ 
sional software engineering. 

An important part of curriculum design 


is specifying educational objectives, 
which the instructor needs for choosing 
both the material and the presentation 
method. Modest objectives can be 
achieved by a superficial presentation, but 
more ambitious objectives require presen¬ 
tations of greater breadth or depth (or 
both). Bloom’s Taxonomy of Educational 
Objectives 6 describes several levels of 
knowledge, intellectual ability, and skills 
that a student might derive from education 
(Figure 3). We adapted this taxonomy to 
help describe the objectives, and thus the 
style and depth of presentation, of a soft¬ 
ware engineering curriculum. 

Because the body of knowledge called 
software engineering is very large, it is 
unreasonable to expect a software engi¬ 
neer to know it all, even at the lowest or 
knowledge level. But, to be productive, an 
engineer must know some material at the 
much higher synthesis level. The curricu¬ 
lum design must carefully identify overall 
educational objectives, as well as individ- 


Evaluation: The student is able to make qualitative and quantitative judgments 
about the value of methods, processes, or artifacts. This includes the ability to 
evaluate conformance to a standard and the ability to develop evaluation criteria, 
as well as apply given criteria. The student can also recognize improvements 
that might be made to a method or process and suggest new tools or methods. 

Synthesis: The student is able to combine elements or parts to produce a 
pattern or structure that was not clearly there before. This includes the 
ability to produce a plan to accomplish a task such that the plan satisfies 
the requirements of the task, as well as the ability to construct an artifact. 

It also includes the ability to develop a set of abstract relations either to 
classify or to explain particular phenomena and to deduce new proposi¬ 
tions from a set of basic propositions or symbolic representations. 

Analysis: The student can identify the constituent elements of a 
communication, artifact, or process and can identify the 
hierarchies or other relationships among those elements. 

General organizational structures can be identified. Unstated 
assumptions can be recognized. 

Application: The student is able to apply abstractions in particu¬ 
lar and concrete situations. Technical principles, techniques, 
and methods can be remembered and applied. The mechanics 
of the use of appropriate tools have been mastered. 

Comprehension: This is the lowest level of understanding. 

The student can make use of material or ideas without 
necessarily relating them to others or seeing the fullest 
implications. Comprehension can be demonstrated by 
rephrasing or translating information from one form of 
communication to another, by explaining or summarizing 
information, or by extrapolating beyond the given situation. 

Knowledge: The student learns terminology and facts. 

This can include knowledge of the existence and names 
of methods, classifications, abstractions, generaliza¬ 
tions, and theories, but it does not include any deep 
understanding of them. The student demonstrates this 
knowledge only by recalling information. 



Figure 3. Bloom’s taxonomy of educational objectives. 
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ual course objectives. The backgrounds, 
capabilities, and career goals of the stu¬ 
dents, the faculty and equipment resources, 
and the time available are some of the 
factors to consider in defining objectives. 

Specific educational objectives, sum¬ 
marized below, may be found in greater 
detail in the descriptions of individual 
curriculum units in the “Curriculum con¬ 
tent” section. 

Knowledge. In addition to knowledge 
about all material described in subsequent 
paragraphs, students should be aware of 
the existence of models, representations, 
methods, and tools other than those they 
learn to use in their studies. Students 
should be aware that there is always more 
to learn and that, whatever techniques they 
learned in school, they will encounter more 
in their professional careers. 

Comprehension. Students should under¬ 
stand the software engineering process, in 
the sense of both abstract models and in¬ 
dustrial practice. They should understand 
the activities and aspects of the process. 
They should understand the issues (some¬ 
times called “the software crisis”) that are 
motivating the growth and evolution of the 
software engineering discipline. They 
should understand the differences between 
academic or personal programming and 
software engineering — in particular, that 
software engineering involves producing 
software systems under the constraints of 
control and management activities. They 
should understand a reasonable set of prin¬ 
ciples, models, representations, methods, 
and tools, and the role of analysis and 
evaluation in software engineering. They 
should understand the existing design 
paradigms for well-understood systems, 
such as compilers. They should know of, 
and comprehend the content of, appropri¬ 
ate standards. They should understand the 
fundamental economic, legal, and ethical 
issues of software engineering. 

Application. Students should be able to 
apply fundamental principles to the per¬ 
formance of the various activities. They 
should be able to apply a reasonable set of 
formal methods to achieve results. They 
should be able to use a reasonable set of 
tools covering all activities of the software 
process. They should be able to collect 
appropriate data for project management 
purposes and for analysis and evaluation of 
both the process and the product. They 
should be able to execute a plan, such as a 
test plan, a quality assurance plan, or a 



The prerequisites 
for the MSE degree 
must be defined 
carefully and must 
be enforceable and 
enforced. 


configuration management plan; this in¬ 
cludes performing various software tests. 
They should be able to apply documenta¬ 
tion standards to all kinds of document 
production. 

Analysis. Students should be able to 
participate in technical reviews and in¬ 
spections of various software work prod¬ 
ucts, including documents, plans, designs, 
and code. They should be able to analyze 
customers’ needs. 

Synthesis. Students should be able to 
perform the activities leading to various 
software work products, including require¬ 
ments specifications, designs, code, and 
documentation. They should be able to 
develop plans, such as project plans, qual¬ 
ity assurance plans, test plans, and con¬ 
figuration management plans. They should 
be able to structure and design data for 
software tests. They should be able to 
prepare oral presentations and to plan and 
lead software technical reviews and in¬ 
spections. 

Evaluation. Students should be able to 
evaluate software work products for con¬ 
formance to standards. They should know 
and use appropriate qualitative and quanti¬ 
tative measures and in evaluating software 
products — for example, in evaluating 
requirements specifications for consis¬ 
tency and completeness or in measuring 
performance. They should be able to verify 
and validate software, considering all sys¬ 
tem requirements, not just functional and 
performance requirements. They should 
be able to apply and validate predictive 
models, such as those for software reliabil¬ 
ity or project cost estimation. They should 
be able to evaluate new technologies and 
tools to determine applicability to their 
own work. 

The words “appropriate” and “reason¬ 
able” occur several times above. Because 


the software engineering discipline is new 
and changing, there is no consensus on the 
best set of representations, methods, or 
tools. Each implementation of the MSE 
curriculum must be structured to match the 
goals and resources of the individual 
school and its students. 

Prerequisites. An undergraduate de¬ 
gree in computer science is the most desir¬ 
able prerequisite for the MSE degree, but 
most practitioners who wish to pursue the 
MSE degree do not have a CS degree. 
Furthermore, students with a bachelor’s 
degree in computer science from different 
schools, or from the same school but five 
years apart, are likely to have substantially 
different knowledge. Thus, the prerequi¬ 
sites for the MSE degree must be defined 
carefully and must be enforceable and 
enforced. 

The primary prerequisite is substantial 
knowledge of programming-in-the-small. 
This includes a working knowledge of at 
least one modem, high-level language (for 
example, Pascal, Modula-2, Ada) and one 
assembly language. Also important is a 
knowledge of fundamental programming 
concepts, including control and data struc¬ 
tures, modularity, data abstraction and 
information hiding, and language imple¬ 
mentations (runtime environments, proce¬ 
dure linkage, and memory management). 
Students should also be familiar with the 
tools of the trade, meaning a user’s knowl¬ 
edge (not a designer’s knowledge) of 
computer organization and architecture, 
operating systems, and typical software 
tools (editor, assembler, compiler, linking 
loader, etc.). An appreciation of formal 
methods and models is also essential, in¬ 
cluding analysis of algorithms and the 
fundamentals of computability, automata, 
and formal languages. Most or all of this 
material is likely to be found in the first 
three years of an undergraduate computer 
science degree program. 

Knowledge of one or more other major 
areas of computer science is highly desir¬ 
able, but not absolutely necessary. Ex¬ 
amples are functional and declarative lan¬ 
guages, numerical methods, database sys¬ 
tems, compiler construction, computer 
graphics, and artificial intelligence. This 
material is usually found in senior-level 
electives in a computer science degree 
program. Some schools may choose to 
allow advanced computer science courses 
as electives in the MSE program. Knowl¬ 
edge of major applications areas in the 
sciences and engineering may also be use¬ 
ful. 
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The mathematics prerequisites are those 
commonly required for an undergraduate 
computer science degree: discrete mathe¬ 
matics and some calculus. Some software 
engineering topics may require additional 
mathematical prerequisites, such as proba¬ 
bility and statistics. A student planning a 
career in a particular application area may 
want additional mathematics, such as lin¬ 
ear algebra or differential equations, but 
these are not essential prerequisites for the 
mainstream courses. 

Enforcing the prerequisites can be diffi¬ 
cult. A lesson can be learned from the 
experience with master’s degree programs 
in computer science. In the 1960s and 
1970s, these programs often served as re¬ 
training programs for students with under¬ 
graduate degrees in other fields (notably 
mathematics and engineering), rather than 
as advanced degree programs for students 
with an undergraduate computer science 
degree. In several schools, undergraduate 
computer science majors were not eligible 
for the master’s program because they had 
already taken all or nearly all of the courses 
as undergraduates. 

These programs existed because of the 
clear need for more programmers and 
computer scientists. Applicants did not 
want a second bachelor’s degree, and there 
were not enough applicants with computer 
science degrees to permit enforcement of 
substantial prerequisites. 

To achieve its goals, the proposed MSE 
program must take students well beyond 
the undergraduate computer science de¬ 
gree. Thus, entering students must already 
have approximately that level of knowl¬ 
edge, but their widely varying back¬ 
grounds make it difficult to assess poten¬ 
tial students. Standardized examinations, 
such as the Graduate Record Examination 
in Computer Science, provide only part of 
the solution. 

We recommend that schools consider a 
leveling or immigration course to establish 
prerequisite knowledge, motivate the 
study of software engineering, and intro¬ 
duce the school’s computing facilities and 
tools. Such a course almost never fits into 
the normal school calendar. Rather, it is an 
intensive two- to four-week course sched¬ 
uled just before or after the start of the 
school year. Students attend up to 20 hours 
a week of lectures summarizing the pre¬ 
requisite material. The value of this course 
is not that the students become proficient 
in all the material, but that they become 
aware of deficiencies in their own prepara¬ 
tion. Self-study in parallel with the first 
semester’s courses can often remove most 


The curriculum 
should incorporate an 
experience component 
representing at least 
30 percent of the 
student’s work. 


of these deficiencies. 

Some schools with MSE programs re¬ 
quire one or more years of professional 
software development experience before 
admission. We have not found the argu¬ 
ments for an experience prerequisite suffi¬ 
ciently compelling to recommend it for all 
MSE programs. Other engineering disci¬ 
plines have successful master’s level pro¬ 
grams, and even undergraduate programs, 
without such a prerequisite. Most graduate 
professional degrees do not require it. 

Curriculum content. The MSE cur¬ 
riculum content is described in units, each 
covering a major topic area, rather than 
courses (see pages 66-67). There are three 
reasons for this. First, not every topic area 
contains enough material for a typical 
university course. Second, units can be 
combined into courses in different ways 
for different organizations. (An example 
that maps the units into semester courses 
appears in a later section.) Third, this struc¬ 
ture more readily permits evolution of each 
unit to reflect changes in software engi¬ 
neering knowledge and practice, while 
maintaining the stability of the overall 
curriculum structure. 

Because of strong relationships among 
topics and subtopics, we could not reach 
consensus on an appropriate linear presen¬ 
tation of topics. We do, however, recom¬ 
mend a top-down approach that focuses on 
the software engineering process first; this 
overview is needed to put the individual 
activities in context. Software manage¬ 
ment and control activities are presented 
next, followed by development activities 
and product view topics. 

Social and ethical issues are also impor¬ 
tant to the education and development of a 
professional software engineer. Examples 
are privacy, data security, and software 
piracy. We do not recommend a specific 
course or unit on these issues; rather, we 
encourage instructors to discuss them in 


context in all courses and to set an example 
for students. 

The curriculum topics are described in 
units of unspecified size. Nearly all have a 
software engineering activity as the focus. 
For each unit, we describe the subtopics 
covered, the most important aspects, and 
the educational objectives. 

Software engineering experience 
component. In addition to coursework 
covering the units described above, the 
curriculum should incorporate a software 
engineering experience component repre¬ 
senting at least 30 percent of the student’s 
work. Universities have tried a number of 
approaches to give students this experi¬ 
ence. Table 1 summarizes some ap¬ 
proaches; more detailed examples are 
available from the SEI. 5 

We do not believe that there is only one 
correct model for providing software engi¬ 
neering experience. It can be argued that 
experience is the basis for understanding 
the abstractions of processes that make up 
formal methods and that allow reasoning 
aboutprocesses; therefore, students should 
have the experience first, with some guid¬ 
ance, and then be shown that the formal¬ 
isms are abstractions of what they have 
been doing. We could also argue for teach¬ 
ing “theory” and formalisms first and then 
letting the students try them in capstone 
project courses. 

Regardless of its form, the experience 
component should provide a broad experi¬ 
ence. It is especially important for students 
to experience, if not perform, the control 
and management activities. Without these, 
the project can be little more than ad¬ 
vanced programming. 

MSE curriculum structured as semes¬ 
ter courses. A typical master’s degree 
curriculum requires 30 to 36 semester 
hours* credit. The units described in the 
previous section can be structured as six 
semester courses of three hours each to¬ 
talling 18 semester hours, leaving time for 
the software engineering experience com¬ 
ponent and for some electives. 

(Continued on p.68) 


*Note for readers not familiar with United States uni- 

by the student per week for a semester of about 15 
weeks. A course covers a single subject area of a 
discipline and typically meets three hours per week, 
for which the student earns three semester hours of 
credit. A graduate student with teaching or research 
responsibilities might take three courses (nine semes¬ 
ter hours) each semester; a student without such duties 
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MSE curriculum content units 

1. Software engineering process 

Topics: The software engineering process and software prod¬ 
ucts. All of the software engineering activities. The concepts of 
software process model and software product life-cycle model. 

Aspects: All aspects, as appropriate for the various activities. 

Objectives: Knowledge of activities and aspects. Some com¬ 
prehension of the issues, especially the distinctions among the 
various classes of activities. The students should begin to 
understand the substantial differences between programming, 
as they did it in an undergraduate program, and software engi¬ 
neering, as it is practiced professionally. 

2. Software evolution 

Topics: The concept of a software product life cycle. The vari¬ 
ous forms of a software product, from initial conception through 
development and operation to retirement. Controlling activities 
and disciplines to support evolution. Planned and unplanned 
events that affect software evolution. The role of changing tech¬ 
nology. 

Aspects: Models of software evolution, including development 
life-cycle models such as the waterfall, iterative enhancement, 
phased development, spiral. 

Objectives: Knowledge and comprehension of the models. 
Knowledge and comprehension of the controlling activities. 

3. Software generation 

Topics: Various methods of software generation, including 
designing and coding from scratch, use of reusable components 
(including examples such as mathematical procedure libraries, 
packages designed specifically for reuse, Ada generic program 
units, and program concatenation as with pipes), use of pro¬ 
gram or application generators and very high level languages, 
role of prototyping. Factors affecting choice of a software gen¬ 
eration method. Effects of generation method on other software 
development activities, such as testing and maintenance. 

Aspects: Models of software generation. Representations for 
software generation, including design and implementation lan¬ 
guages, very high level languages, and application generators. 
Tools to support generation methods, including application gen¬ 
erators. 

Objectives: Knowledge and comprehension of the various 
methods of software generation. Ability to apply each method 
when supported by appropriate tools. Ability to evaluate meth¬ 
ods and choose the appropriate ones for each project. 

4. Software maintenance 

Topics: Maintenance as a part of software evolution. Reasons 
for maintenance. Kinds of maintenance (perfective, adaptive, 
corrective). Comparison of development activities during initial 
product development and during maintenance. Controlling ac¬ 
tivities and disciplines that affect maintenance. Designing for 
maintainability. Techniques for maintenance. 

Aspects: Models of maintenance. Current methods. 

Objectives: Knowledge and comprehension of the issues of 
software maintenance and current maintenance practice. 

5. Technical communication 

Topics: Fundamentals of technical communication. Oral and 
written communications. Preparing oral presentations and sup¬ 
porting materials. Software project documentation of all kinds. 

Aspects: Principles of communication. Document preparation 
tools. Standards for presentations and documents. 

Objectives: Knowledge of fundamentals of technical commu¬ 
nication and of software documentation. Application of funda¬ 
mentals to oral and written communications. Ability to analyze, 
synthesize, and evaluate technical communications. 


6. Software configuration management 

Topics: Concepts of configuration management. Its role in 
controlling software evolution. Maintaining product integrity. 
Change control and version control. Organizational structures 
for configuration management. 

Aspects: Fundamental principles. Tools (such as SCCS or 
RCS). Documentation, including configuration management 
plans. 

Objectives: Knowledge and comprehension of the issues. 
Ability to apply the knowledge to develop a configuration man¬ 
agement plan and to use appropriate tools. 

7. Software quality issues 

Topics: Definitions of quality. Factors affecting software qual¬ 
ity. Planning for quality. Quality concerns in each phase of a 
software life cycle, with special emphasis on the specification of 
the pervasive system attributes. Quality measurement and stan¬ 
dards. Software correctness assessment principles and meth¬ 
ods. The role of formal verification and the role of testing. 

Aspects: Assessment of software quality: appropriate meas¬ 
ures. Tools to help perform measurement. Correctness assess¬ 
ment methods, including testing and formal verification. Formal 
models of program verification. 

Objectives: Knowledge and comprehension of software qual¬ 
ity issues and correctness methods. Ability to apply proof of cor¬ 
rectness methods. 

8. Software quality assurance 

Topics: Software quality assurance as a controlling discipline. 
Organizational structures for quality assurance. Independent 
verification and validation teams. Test and evaluation teams. 
Software technical reviews. Software quality assurance plans. 

Aspects: Current industrial practice for quality assurance. 
Documents including quality assurance plans, inspection re¬ 
ports, audits, and validation test reports. 

Objectives: Knowledge and comprehension of quality assur¬ 
ance planning. Ability to analyze and synthesize quality assur¬ 
ance plans. Ability to perform technical reviews. Knowledge and 
comprehension of the fundamentals of program verification, and 
its role in quality assurance. Ability to apply concepts of quality 
assurance as part of a quality assurance team. 

9. Software project organizational and management issues 

Topics: Project planning: choice of process model, project 
scheduling and milestones. Staffing: development team organi¬ 
zations, quality assurance teams. Resource allocation. 

Aspects: Fundamental concepts and principles. Scheduling 
representations and tools. Project documents. 

Objectives: Knowledge and comprehension of concepts and 
issues. It is not expected that a student, after studying this ma¬ 
terial, will immediately be ready to manage a software project. 

10. Software project economics 

Topics: Cost estimation, cost/benefit analysis, risk analysis 
for software projects. Factors that affect cost. 

Aspects: Models of cost estimation. Current techniques and 
tools for cost estimation. 

Objectives: Knowledge and comprehension of models and 
techniques. Ability to apply the knowledge to tool use. 

11. Software operations issues 

Topics: Organizational issues related to the use of a software 
system in an organization. Training, system installation, system 
transition, operation, retirement. User documentation. 

Aspects: User documentation and training materials. 

Objectives: Knowledge and comprehension of the major issues. 
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12. Requirements analysis 

Topics: The process of interacting with the customer to deter¬ 
mine system requirements. Defining software requirements. 
Identifying functional, performance, and other requirements: the 
pervasive system requirements. Techniques to identify require¬ 
ments, including prototyping, modeling, and simulation. 

Aspects: Principles and models of requirements. Techniques 
of requirement identification. Tools to support these techniques, 
if available. Assessing requirements. Communication with the 
customer. 

Objectives: Knowledge and comprehension of the concepts of 
requirements analysis and the different classes of requirements. 
Knowledge of requirements analysis techniques. Ability to apply 
techniques and analyze and synthesize requirements for simple 
systems. 

13. Specification 

Topics: Objectives of the specification process. Form, con¬ 
tent, and users of a specifications document. Specifying func¬ 
tional, performance, reliability, and other requirements of sys¬ 
tems. Formal models and representations of specifications. 
Specification standards. 

Aspects: Formal models and representations. Specification 
techniques and tools that support them, if available. Assess¬ 
ment of a specification for attributes such as consistency and 
completeness. Specification documents. 

Objectives: Knowledge and comprehension of the fundamen¬ 
tal concepts of specification. Knowledge of specification mod¬ 
els, representations, and techniques, and the ability to apply or 
use one or more. Ability to analyze and synthesize a specifica¬ 
tion document for a simple system. 

14. System design 

Topics: The role of system design and software design. How 
design fits into a life cycle. Software as a component of a sys¬ 
tem. Hardware vs. software trade-offs for system performance 
and flexibility. Subsystem definition and design. Design of high- 
level interfaces, both hardware to software and software to soft¬ 
ware. 

Aspects: System modeling techniques and representations. 
Methods for system design, including object-oriented design, 
and tools to support those methods. Iterative design techniques. 
Performance prediction. 

Objectives: Comprehension of the issues in system design, 
emphasizing engineering trade-offs. Ability to use appropriate 
system design models, methods, and tools, including those for 
specifying interfaces. Ability to analyze and synthesize small 
systems. 

15. Software design 

Topics: Principles of design, including abstraction and infor¬ 
mation hiding, modularity, reuse, prototyping. Levels of design. 
Design representations. Design practices and techniques. Ex¬ 
amples of design paradigms for well-understood systems. 

Aspects: Principles of software design. One or more design 
notations or languages. One or more widely used design meth¬ 
ods and supporting tools, if available. Assessment of the quality 
of a design. Design documentation. 

Objectives: Knowledge and comprehension of one or more 
design representations, design methods, and supporting tools, if 
available. Ability to analyze and synthesize designs for software 
systems. Ability to apply methods and tools as part of a design 
team. 


16. Software implementation 

Topics: Relationship of design and implementation. Features 


of modern procedural languages related to design principles. 
Implementation issues including reusable components and ap¬ 
plication generators. Programming support environment con¬ 
cepts. 

Aspects: One or more modern implementation languages and 
supporting tools. Assessment of implementations: coding stan¬ 
dards and metrics. 

Objectives: Ability to analyze, synthesize, and evaluate the 
implementation of small systems. 

17. Software Testing 

Topics: The role of testing and its relationship to quality as¬ 
surance. The nature of and limitations of testing. Levels of test¬ 
ing: unit, integration, acceptance, etc. Detailed study of testing 
at the unit level. Formal models of testing. Test planning. Black 
box and white box testing. Building testing environments. Test 
case generation. Test result analysis. 

Aspects: Testing principles and models. Tools to support spe¬ 
cific kinds of tests. Assessment of testing; testing standards. 
Test documentation. 

Objectives: Knowledge and comprehension of the role and 
limitations of testing. Ability to apply test tools and techniques. 
Ability to analyze test plans and test results. Ability to synthe¬ 
size a test plan. 

18. System integration 

Topics: Testing at the software system level. Integration of 
software and hardware components of a system. Uses of simu¬ 
lation for missing hardware components. Strategies for gradual 
integration and testing. 

Aspects: Methods and supporting tools for system testing and 
system integration. Assessment of test results and diagnosing 
system faults. Documentation: integration plans, test results. 

Objectives: Comprehension of the issues and techniques of 
system integration. Ability to apply the techniques to do system 
integration and testing. Ability to develop system test and inte¬ 
gration plans. Ability to interpret test results and diagnose sys¬ 
tem faults. 

19. Embedded real-time systems 

Topics: Characteristics of embedded real-time systems. Exis¬ 
tence of hard timing requirements. Concurrency in systems and 
representing concurrency in requirements specifications, de¬ 
signs, and code. Issues related to complex interfaces between 
devices and between software and devices. Criticality of em¬ 
bedded systems and issues of robustness, reliability, and fault 
tolerance. Input and output considerations, including unusual 
data representations required by devices. Issues related to the 
cognizance of time. Issues related to the inability to test sys¬ 
tems adequately. 

Objectives: Comprehension of the significant problems in the 
analysis, design, and construction of embedded real-time sys¬ 
tems. Ability to produce small systems that involve interrupt 
handling, low level input and output, concurrency, and hard tim¬ 
ing requirements, preferably in a high level language. 

20. Human interfaces 

Topics: Software engineering factors: applying design tech¬ 
niques to human interface problems, including concepts of de¬ 
vice independence and virtual terminals. Human factors: defini¬ 
tion and effects of screen clutter, assumptions about the class 
of users of a system, robustness and handling of operator input 
errors, uses of color in displays. 

Objectives: Comprehension of the major issues. Ability to ap¬ 
ply design techniques to produce good human interfaces. Ability 
to design and conduct experiments with interfaces, to analyze 
the results, and to improve the design as a result. 
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Table 1. Approaches to the experience component. 


School 

Approach 

Description 

Seattle University, 

Monmouth College, 

Texas Christian University 

Capstone project course 

Students do a software development project after completion 
of most coursework. 

University of 

Southern California 

Continuing project 

Students participate in the Software Factory, a project that 
continues from year to year, building and enhancing software 
engineering tools and environments. 

Arizona State University 

Multiple-course 
coordinated project 

A single project is carried through four courses on software 
analysis, design, testing, and maintenance; students may 
take the courses in any order. 

University of Stirling 

Industry cooperative 
program 

After one year of study, students spend six months in industry 
on a professionally managed software project, followed by a 
semester of project or thesis work based in part on the work 
experience. 

Imperial College 

Commercial software 
company 

Students participate in projects of a commercial software 
company that has been established by the college in 
cooperation with local companies. 

Carnegie Mellon University 

Design studio 

Students work on a project under the direction of an 
experienced software designer in somewhat of a master- 
apprentice relationship. 


(Continued from p.65) 

Figure 4 shows the six core courses with 
the curriculum units comprising each 
course. In some cases a unit name appears 
twice because the material can logically be 
split across two courses. Detailed descrip¬ 
tions of these courses are being developed 
at the SEI through a series of curriculum 
design workshops. 5 

The technical-communication unit does 
not appear in the six core courses. We 
recommend its integration into all courses. 
For example, oral presentation skills can 
be taught with software technical reviews, 
and writing skills can be covered with 
documents in the first course. These skills 
should be reinforced by requiring written 
documents and oral presentations through¬ 
out the curriculum. In the past, many sci¬ 
ence and engineering instructors have been 
reluctant to make technical communica¬ 
tion a factor in student evaluations and 
grades. Because of its importance in soft¬ 
ware engineering, we strongly urge in¬ 
structors to make it an integral part of all 
appropriate courses. 

Because the core courses focus almost 
exclusively on the software engineering 


process, we recommend focusing electives 
on the product. Elective courses based on 
particular system classes (such as distrib¬ 
uted systems or expert systems) or on per¬ 
vasive system attributes (such as software 
fault tolerance or reliability) will comple¬ 
ment the process courses. Other electives 
can be chosen from advanced computer 
science or application domains. 

Because of the wide range of choices for 
electives, students can be well served by 
creative course design. For example, sev¬ 
eral small units of material (roughly one 
semester hour each) might be prepared by 
several different instructors. Three of these 
could be offered sequentially in one se¬ 
mester, under the title “Topics in Software 
Engineering,” with different units offered 
in different semesters. 

Figure 5 shows the prerequisite struc¬ 
ture for a curriculum based on these six 
courses. This structure reflects the familiar 
spiral approach to education, in which 
material is presented several times in in¬ 
creasing depth. This approach is essential 
for a discipline, such as software engineer¬ 
ing, with many complex interrelationships 
among topics, because no simple linear 
ordering of the material exists. 


Students learn the basics of computer 
science and programming-in-the-small in 
the undergraduate curriculum. The six core 
courses build on these basics by adding 
depth, more formal methods, and the pro- 
gramming-in-the-large concepts associ¬ 
ated with systems engineering and control 
and management activities. The electives 
and the project experience component 
provide further depth and an opportunity 
for specialization. 

Future of software 
engineering education 

As an emerging discipline, software 
engineering will challenge educators to 
keep pace, and the next 10 to 15 years will 
bring many changes to the structure of its 
academic programs. 

We expect a continuation of the distinc¬ 
tion between computer science and soft¬ 
ware engineering. Also, even though we 
expect an overall increase in the resources 
devoted to education in these two fields, 
software engineering education will 
probably grow at a faster rate than the two 
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combined, thus siphoning off some re¬ 
sources currently devoted to computer 
science education. However, since few 
universities will establish separate aca¬ 
demic departments anytime soon, the re¬ 
source trade-offs will be intradepartmental 
and relatively easy to handle. 

Undergraduate education. Because of 
the discipline’s immaturity, an under¬ 
graduate degree in software engineering is 
probably premature. This is not to say that 
undergraduates should not be taught any¬ 
thing about software engineering. In re¬ 
cent years, there have been more than five 
times as many bachelor’s degrees as mas¬ 
ter’s degrees in computer science awarded 
by United States universities. This indi¬ 
cates that perhaps 80 percent of persons 
beginning careers in software engineering 
will never pursue an advanced degree. 
Therefore, it is important to increase the 
quality and quantity of the software engi¬ 
neering content in undergraduate com¬ 
puter science programs. 

We believe there are two immediate 
trends in undergraduate software engineer¬ 
ing education. The first is the adoption of a 
senior-level software engineering course 
in existing computer science degree pro¬ 
grams. The second is continued evolution 
of lower level programming courses in the 
direction of increased consideration of 
concepts and language features that sup¬ 
port programming-in-the-large, primarily 
data abstraction, information hiding, con¬ 
currency, and exception handling. 

There are also two longer term possibili¬ 
ties in undergraduate software engineering 
education. The first is the development of 
an undergraduate degree with the same 
kind of expectations of its graduates as is 


now the case with traditional undergradu¬ 
ate engineering degrees. As the distinc¬ 
tions between computer science and soft¬ 
ware engineering become clearer, separate 
undergraduate programs may emerge. Ini¬ 
tially, the two programs might have one or 
two years of common studies, much as the 
traditional engineering disciplines share 
an engineering core. The third year might 
also have some common courses, but the 
fourth year might be entirely different for 
the two programs. 

As the programs mature, however, even 
first-year courses are apt to differ. We can 
see these differences in current engineer¬ 
ing education. For example, in many 
schools a course in differential equations 
for mathematicians is concerned with 
proving the existence and uniqueness theo¬ 
rems, while a course for engineers is 
concerned with methods for solving differ¬ 
ential equations. Similar differences in 
teaching can be anticipated for computer 
science and software engineering students. 

A second, quite different possibility for 
undergraduate education is based on the 
expectation of some members of the soft¬ 
ware engineering community that the pro¬ 
fession will partition itself into at least two 
skill levels. Software engineers at the 
higher level will be project leaders, system 
architects, and designers, while those at 
the lower levels will be skilled in the use of 
particular software tools or in performing 
particular tasks, such as testing. The two 
levels of practitioners will require differ¬ 
ent levels of education and experience, the 
higher level requiring an MSE degree and 
the lower level perhaps a bachelor’s de¬ 
gree. 

There are precedents for this kind of 
partitioning. The data processing commu¬ 


nity distinguishes systems analysts from 
coders, and the engineering community is 
supported by engineering technicians. It is 
too soon to see clear trends in software 
engineering, but the SEI Education Pro¬ 
gram plans to continue monitoring the 
profession. 

Graduate education. A professional 
MSE degree, with preliminary content as 
suggested in this report, is our current 
recommendation for the most effective 
graduate education. 

The software community generally 
agrees that experience plays a leading role 
in the development of a good software 
engineer. Some persons have suggested 
that software engineering look to medicine 
for educational models such as internships, 
residencies, and teaching hospitals. Thus, 
the SEI will continue investigating the 
structure of the MSE program’s experien¬ 
tial component. 

Doctoral-level education in software 
engineering is also a possibility. George 
Mason University and Boston University 
are continuing the development, begun by 
the Wang Institute of Graduate Studies, of 
a program leading to a PhD in software 
engineering. The rapid growth of software 
engineering as an academic discipline 
leads us to believe such programs will 
begin appearing in the 1990s. □ 
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Do standards cause software problems? 


Fletcher J. Buckley, GE Aerospace 

The typical project manager must pro¬ 
duce important products with inadequate 
funding, impossible schedules, and lim¬ 
ited staff. 

In preparing procurement documents, 
the project manager looks for quick fixes 
— things that do not take much thought to 
implement and that allow the project to 
immediately move ahead, meet the next 
milestone, etc. For example, tradition in 
the computer field holds that software 
will be a problem on every project, so the 
typical project manager will reach for the 
nearest set of software standards, write 
those into the contract, and rush off to the 
next problem. This is the point where 
standards may become the cause of prob¬ 
lems that they purport to cure. 

Standards come in various packages 
and usually need to be applied in a knowl¬ 
edgeable manner. For example, one se¬ 
ries of documents relates to the develop¬ 
ment of software to include standards for 
requirements documents and design 
documents. Requirements documents 
identify the capabilities the resulting 
computer program is to have, including 
the functions that the item is to perform, 
the external interfaces, design con¬ 
straints, performance requirements, etc. 
These requirements documents are for¬ 
mal agreements with the customer on 
what the software will do and, as such, are 
formally controlled. Any changes to 
these requirements normally require the 
signatures of both parties as part of the 
change approval cycle. 

Design documents describe how to 
construct the item. They are agreements 
between elements inside the developer’s 
organization. Design documents are not 
subject to customer agreement. Recog¬ 
nizing customer concern about progress, 
developers usually provide visibility into 
the construction process. However, visi¬ 
bility is not control, and customer signa¬ 
tures are not required as part of the change 
control process. 

To provide a very specific example, 
consider DoD-Std-2167A, “Defense 
System Software Development.” This 
comprehensive document includes, in its 
attached DI-MCCR-80025A, precise cri¬ 
teria for the format and content of software 
requirements specifications. As part of 


DI-MCCR-80025A, each required capa¬ 
bility is identified in a uniquely numbered 
paragraph. Unfortunately, however, DI- 
MCCR-80025A also stipulates that the 
requirements specification must include 
the details of the internal interfaces of 
each of the individual capabilities down 
to the associated internal data elements.* 
Providing these internal data interfaces 
in a requirements specification can sub¬ 
stantially affect both the cost and the 
schedule of the design and test efforts of 
software development. 

Impacts in the design effort. Require¬ 
ments specifications now identify spe¬ 
cific data elements. Assuming normal re¬ 
quirements for traceability exist from the 
requirements specifications to the design 
documents, the developer must ensure 
that these data elements appear in the de¬ 
sign. The required capabilities, their 
internal interfaces, and each data element 
must be translated directly into the top- 
level design of the computer program. In 
effect, the requirements specification 
now contains a significant part of the top- 
level design. 

As the developer’s design group starts 
its top-level design, good and sufficient 
reasons for a different partitioning of the 
capabilities may arise. It might be more 
efficient, for example, to perform a dif¬ 
ferent partitioning. Because this affects 
the data elements identified in the 
requirements specifications, a formal 
agreement with the customer is required 
to make that change in the requirements 
specification. The developer now faces a 
series of unpalatable choices. 

As a first choice, the developer can risk 
implementing the recommended change 
while the agreement to be signed by the 
customer is being drafted and processed. 
Assuming a normal 120-day cycle for 
such things, the risk is four months’ loss 
of time and effort. 

As a second choice, the developer can 
implement the old design — the design to 
be changed. (For a software contractor on 
a fixed-price effort, this appears to be the 


* See Section 10.1.5.3 of DI-MCCR-80025A. This 
problem is not unique to DoD-Std-2167A. For ex¬ 
ample, in its prototype outlines, ANSI/IEEE Stan¬ 
dard 830-1984 indicates that the internal interfaces 
should be specified. 


only viable strategy.) This incurs the risk 
of lost time and effort if the recommended 
change is approved. 

The third choice the developer may 
make is to do no work in the area of the 
proposed change and release the people 
to another project. This, too, has both a 
time and money impact. Four months 
have been lost until the proposed change 
is resolved. In addition, the people re¬ 
leased to other projects will probably 
never return. This project must now ac¬ 
quire new people and suffer the associ¬ 
ated learning-curve inefficiencies. 

Things can rapidly become much 
worse. What if, two months after the ini¬ 
tial change in the requirements specifica¬ 
tion is originated, a second change is re¬ 
quired. The situation in the design group 
can become very confused as changes 
pile on top of changes. 

Effects on the test effort. In terms of 
testing, the customer is entitled to a rea¬ 
sonable degree of assurance that every 
item in the requirements specification 
has been implemented in the resulting 
computer program. If internal data ele¬ 
ments are stated in the requirements 
specification, the developer faces a num¬ 
ber of unsatisfactory choices. 

First, the developer can ensure that ev¬ 
ery data element is demonstrated as part 
of the formal test program. This can be ex¬ 
tremely costly. 

Second, the developer can attempt to 
convince the customer that it is unreason¬ 
able to test every data element in the re¬ 
quirements specification. Those going 
down this path should realize that the cus¬ 
tomer may have no incentive to agree 
with that line of logic. Assuming success 
(the customer is now convinced that it is 
unreasonable to require all that testing), 
the customer will usually ask for money 
back from the developer because the 
scope of the testing is reduced from that 
previously agreed to. 

Third, the developer can initiate a 
change to the requirements specification 
to remove the untested material, and then 
follow the second course of action. 

Fourth, the developer can state at the 
beginning of the test plan the level at 
which to do testing. This places the prob¬ 
lem up front in the development cycle and 
allows time for further discussions with- 
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out undue time pressure. It then reverts to 
the second course of action. 

The tailoring solution. To some, the 
solution to this type of problem is for the 
project manager to tailor the standard to 
the project’s needs prior to contract. 

Alas, at this time, reality begins to sink in. 
The project manager’s staff members are 
very busy. They have no time for this type 
of effort. They have many other impor¬ 
tant problems to resolve and are on a tight 
schedule. Further, the staff usually has 
little or no expertise or experience in soft¬ 
ware engineering or software develop¬ 
ment, and resolving these types of prob¬ 
lems does not directly affect them. So, 
nothing is done. 

Others would place the onus for tailor¬ 
ing on the developer. The developer 
should propose tailoring the standards 
prior to accepting the work. This, too, is 
out of touch with reality. The project 
manager needs a clean procurement. To 
do that, all prospective developers must 
be placed on a level technical field from 
which the lowest responsible responsive 
bidder can be chosen. Tailoring a stan¬ 
dard implies that one bidder may have a 
cost advantage over another. This is not 
equitable, so the tailoring request is con¬ 
sidered a nonresponsive bid. Thus, this 
approach also fails. 

The bottom line is: beware the blind, 
unknowledgeable application of stan¬ 
dards. Standards are composed by people 
working with good intentions to solve 
problems. But, standards are not without 
error and need thoughtful application. 
Otherwise, they may cause the very prob¬ 
lems we are trying to resolve. 


To go further 

Copies of DoD-Std-2167A, “Defense 
System Software Development,” are 
available by contacting Commanding 
Officer, Naval Publications and Forms 
Center, 5801 Tabor Ave., Philadelphia, 
PA 19120. 

Copies of ANSI/IEEE Std 830-1984, 
“IEEE Guide to Software Requirements 
Specifications,” can be ordered through 
any IEEE Computer Society office or 
through the IEEE. 

Those wishing to participate in the re¬ 
vision of ANSI/IEEE Std 830-1984 
should circle 185 on the reader service 
card, and those wishing additional infor¬ 
mation on the reviews of DoD-Std-2167A 
can obtain it by circling 186. 


See p. 74 for coverage of testimony on 
international standards given by IEEE 
Computer Society President-elect Helen 
Wood before a Congressional panel. 



DEPARTMENT OF ELECTRICAL 
ENGINEERING 

The Department of Electrical Engineering invites 
applications for teaching and research positions from 
candidates with a PhD degree in one of the following areas : 

Computer Communications 

Computer Systems 

Image Processing/Computer Vision 

Gross annual emoluments range as follows : 

Research Fellow S$44,860 - 64,200 

Lecturer S$53,160 - 64,200 

Senior Lecturer S$58,680 - 100,310 

Associate Professor S$88,650 - 122,870 

(US$1.00 = S$1.97 approximately) 


The commencing salary will depend on the candidate's 
qualifications, experience and the level of appointment offered. 

Leave and medical benefits will be provided. Depending on the 
type of contract offered, other benefits may include : provident 
fund benefits or an end-of-contract gratuity, a settling-in allowance 
of S$1,000 or S$2,000, subsidised housing at nominal rentals 
ranging from SS100 to S$216 p.m., education allowance for up to 
three children subject to a maximum of S$10,000 per annum per 
child, passage assistance and baggage allowance for the 
transportation of personal effects to Singapore. Staff members 
may undertake consultation work, subject to the approval of the 
University, and retain consultation fees up to a maximum of 60% 
of their gross annual emoluments in a calendar year. 

The Electrical Engineering Department has currently an academic 
staff of 48 with 18 laboratories, all of which have excellent 
facilities for teaching and research. Its Microelectronics Laboratory 
has facilities for fabricating ICs in 4-micron polysilicon-gate single 
metal CMOS technology, while its Semiconductor Laboratory has 
a liquid phase epitaxy system for fabricating GaAl As semiconductor 
lasers and will soon acquire a molecular-beam epitaxy system for 
lll-V compounds. A wide range of computing resources are 
available, including numerous PCs, microVaxes, HP9000 Series 
300s and SUN workstations, an additional 15 of which are located 
in the Engineering Faculty CAE Centre. The University Computer 
Centre operates an IBM3081 2KX and IBM4341 and is acquiring 
a high-speed campus-wide network providing each staff member 
with his own PC directly linked to the various computing resources, 
including 2 supercomputers based in the nearby Science Park. A 
number of large-scale research projects are in progress, including 
a S$1M optical LAN joint effort with the Singapore Telecoms. 

Application forms and further information on terms and conditions 
of service may be obtained from : 


The Director 
Personnel Department 
National University of 
Singapore 

10 Kent Ridge Crescent 
Singapore 0511 


North America Office 
National University of 
Singapore 

780, Third Avenue, Suite 
2403, New York, 

NY 10017, USA 
Tel: (212) 751-0331 


Enquiries to current research activities in specific areas may be sent 
through BITNET to : PERSDEPT @ NUSVM 
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Wood urges US to increase its international standards funding support 


Testifying at a US House of 
Representatives hearing July 25, IEEE 
Computer Society President-elect Helen 
M. Wood called on the US government 
to widen its role of promoting interna¬ 
tional standardization by increasing 
much-needed allocations to the US 
National Institute for Standards and 
Technology (NIST). 

Wood, appearing at the invitation of 
the House Subcommittee on Science, 
Research, and Technology, said that 
standardization is a major interest of 
Computer Society members and, there¬ 
fore, she welcomed the opportunity to 
address the panelists. The Washington, 
DC, hearing was called to explore how 
the US can improve its competitive 
position in international trade through 
more active involvement in interna¬ 
tional standards development. 

“Effective federal participation in 
international standards activities will 
not only enable the government to 
develop standards needed for its own 
cost-effective operation, but... will 
improve the overall effectiveness of US 
participation in international standardi¬ 
zation,” she said. 

Wood, who also directs the real-time 
processing of data from meteorological 
satellites of the National Oceanic and 
Atmospheric Administration within the 
US Dept, of Commerce, said she was 
solely speaking on behalf of the Com¬ 
puter Society at the hearing and not the 
Commerce Dept, or the NOAA. 

She said the IEEE has been urging 
steps to increase NIST’s overall budget 
for more than two years and that IEEE 
representatives repeated the institute’s 
position last April in an appearance 
before a subcommittee of the House 
Appropriations Committee. 

“The IEEE again stated that there 
can be little doubt why the international 
competitive position of the United 
States continues to decline when the 
federal government does not adequately 
support its own standards role,” said 
she. 

At least two criteria must be met, 
Wood said, if US interests are to be 


effectively represented in international 
standardization activities: 

(1) the interests of both vendors and 
users must be a represented, and 

(2) adequate resources must be 
provided for administrative support. 

“Recently, the American National 
Standards Institute has made a number 
of improvements in its support of US 
interests in the growing area of interna¬ 
tional information technology stan¬ 
dards,” said Wood. “A new oversight 
committee has been formed, and fund¬ 
ing is being solicited from organizations 
interested in this area of standardiza¬ 
tion. While the results have been 
encouraging, the need still exists for 
increased federal participation in all 
levels of the international standards 
process.” 

Wood concluded by saying that 
“effective representation of US 
interests in high-priority, international 
standardization activities is essential for 
the economic health of our nation in 
international trade.” 

Computer Society’s role. Earlier in 
her statement, Wood said that draft 
standards developed under Computer 
Society sponsorship are forwarded to 
the IEEE for adoption and, if approved 
by the IEEE, are submitted to the ANSI 
for recognition as American National 
Standards. 

The ANSI plays a vital role in US 
international standardization interests, 
Wood said. As the member body 
representing the US in both the Interna¬ 
tional Standards Organization and the 
International Electrotechnical Commis¬ 
sion, the ANSI administers US partici¬ 
pation in ISO and IEC activities. 

Operationally, this requires fast and 
orderly distribution of massive amounts 
of documents, monitoring of extensive 
due-date schedules, appointing US 
delegates to meetings, and the timely 
processing and forwarding of US posi¬ 
tion papers, votes, and technical contri¬ 
butions to the appropriate bodies. The 
ANSI requires a knowledgeable, dedi¬ 
cated staff and ever-increasing financial 


resources to carry out these duties effec¬ 
tively. 

Wood said a number of society- 
sponsored standards have been adopted 
by the ISO and IEC. Such society stan¬ 
dards have “widespread effects on 
products and practices throughout all 
sectors of the global economy,” said 
Wood. 

She said, for example, that IEEE 802 
standards for local area networks have 
been adopted by the ISO as part of the 
Open Systems Interconnection family 
of standards. In addition, IEEE 1003 
Posix standards define a portable appli¬ 
cations environment that permits appli¬ 
cations software to run on systems from 
many different vendors. 

Wood said standards developed 
under Computer Society sponsorship 
are well received around the world, in- 
part due to the amount of international 
participation that exists within many of 
the society’s standards working groups. 
The society has recently been 
encouraged to submit more of its stan¬ 
dards for international consideration. 

Federal international standards 
aspect. The federal government has 
played a substantial role in the develop¬ 
ment of US information technology 
standards for many years—often as the 
only participant representing the 
interests of technology users, Wood 
said. Today, many information technol¬ 
ogy standards are first developed within 
the international standardization pro¬ 
cess and then adopted by national stan¬ 
dards bodies. “This approach, when 
successful, tends to preclude the devel¬ 
opment of dissimilar national standards 
that impede free trade,” she added. 

“However, today’s tight budgets 
have made it extremely difficult for the 
federal government to provide needed 
support for high priority, international 
technology standards within the US, 
much less internationally. Limited fed¬ 
eral participation in international stan¬ 
dards activities hinders, in effect, the 
representation of all US interests in that 
process. 
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“Not only are the interests of govern¬ 
ment and industry users often absent, 
but delegations comprised of US ven¬ 
dors are usually regarded with suspicion 
by foreign delegates—a reaction that 
adds further complications to an 
already difficult negotiation process.” 

Congressman Doug Walgren (D-Pa.), 
chairman of the Science, Research, and 
Technology Subcommittee, said that 


the merging of western Europe into one 
market through the Europe 1992 pro¬ 
cess has made governmental roles in 
international standards development 
much more important than in the past. 
Governmental representatives of the 
Common Market nations are in the pro¬ 
cess of drafting common standards 
that, for the first time, will permit 
qualifying products to be sold through¬ 
out western Europe, he said. 


“Increasingly, nations are using their 
ability to influence product standards as 
a trade weapon,” the congressman said. 
“Countries that give less than their best 
effort now do so at their own peril.” 

Representative Sherwood L. Boehlert 
(R-NY) commented that “given the 
magnitude of what is at stake, we need 
to decide whether the government ought 
to be taking a more direct and active 
role” in international standardization. 


Society’s Outstanding 
Contribution Certificate 
presented to Jim Blinn 

James F. Blinn, who writes a popular 
IEEE Computer Graphics and Applica¬ 
tions column and is known in the indus¬ 
try as “Mr. Computer Graphics,” was 
presented the Computer Society’s Out¬ 
standing Contribution Certificate 
August 1. Blinn was cited at SIGGraph 
in Boston. 

At the 26th Design Automation Con¬ 
ference in Las Vegas June 26, Vishwani 
Agrawal of AT&T and Donald E. 
Thomas of Carnegie Mellon University 
received Meritorious Service Certifi¬ 
cates; William A. Dees of Cadence 
Design Systems and Thomas P. Pen- 
nino of AT&T Bell Laboratories 
received Certificates of Appreciation; 
and Prathima Agrawal of AT&T and 
Donald Thomas received IEEE Fellow 
certificates (see Computer, March 1989, 
pp. 74-75). 

Blinn was cited for distinguished ser¬ 
vice to computer graphics professionals 
through his “Jim Blinn’s Corner” 
column in CG&A. Active in computer 
graphics since 1967, he began writing 
the column in August 1987. The feature 
consists of specialized information for 
computer graphicists. Blinn also serves 
as associate director of Project 
Mathematics at the California Institute 
of Technology and is producing a series 
of animations for use in teaching high 
school math. 

Vishwani Agrawal was honored for 
many years of dedicated service on the 
International Test Conference Program 
Committee; Donald Thomas, for 
leadership in making DAC 26 an out¬ 
standing conference as chair and for 
technical program leadership from 1983 
to 1987; Dees, for dedicated contribu¬ 
tions to the DAC series, including ser¬ 
vice as audiovisual chair in 1987-88; and 
Pennino, for DAC leadership and con¬ 
tributions, including service as publicity 
chair in 1987-88 and exhibits technical 
program chair in 1989. 



Jim Blinn received the IEEE Computer Donald Thomas received a Meritorious 
Society Outstanding Contribution Cer- Service Certificate and his IEEE Fellow 
tificate at SIGGraph August L _ certificate at DAC 26. 



Computer Society President Ken Anderson (left) presented an IEEE Fellow certifi¬ 
cate to Prathima Agrawal (center) and a Meritorious Service Certificate to Vish¬ 
wani Agrawal at the 26th Design Automation Conference. 



William Dees (left photo) and Thomas Pennino (right photo) each received the 
Computer Society’s Certificate of Appreciation on June 26 during this year’s 
Design Automation Conference, held in Las Vegas. 
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Harriett Rigas, Division V representative on IEEE board, passes away 


Harriett B. Rigas, a member of the 
IEEE Board of Directors as Computer 
Society Division V Director as well as a 
former member of the Computer Soci¬ 
ety Board of Governors, died July 26 in 
East Lansing, Michigan. Death was 
attributed to kidney and lung cancer. 
Graveside services were held in Michi¬ 
gan July 29. 

An IEEE Fellow and distinguished 
educator and administrator, Rigas, 55, 
was a veteran IEEE and Computer 
Society volunteer and held a number of 
posts in the institute dating back to 
1974-75 when she was a member of the 
Spokane (Washington) Section Execu¬ 
tive Committee. She served on the soci¬ 
ety’s board from 1984 to 1986 and was 
in her second year as a member of the 
IEEE board at the time of her death. 

“Harriett Rigas was the nation’s and 
probably the world’s leading woman 
electrical engineer,” said Martha Sloan, 
who was president of the Computer 
Society during Rigas’ term on the soci¬ 
ety’s board. 

During her career, Rigas served as 
department head of three electrical 
engineering departments (Washington 
State University, the Naval Postgradu¬ 
ate School, and, since 1987, Michigan 
State University) and headed a major 
program at the National Science Foun¬ 
dation. 



Harriett Rigas died July 26. 


“She earned the Achievement Award 
of the Society of Women Engineers [in 
1982], its highest honor,” Sloan said. 
“In addition, she was the newly elected 
chairperson of the National Electrical 
Engineering Department Heads Associ¬ 
ation and had for years served on the 
Engineering Accreditation Commission 
of the Accreditation Board for 
Engineering and Technology. 


“Harriett will be sadly missed; she 
was everywhere,” Sloan added. 

Rigas served on the Computer Soci¬ 
ety’s Fellows Committee in 1984-87 and 
Awards Committee in 1988. Her 
numerous IEEE activities also included 
chairing the Educational Activities 
Board Minorities Committee in 
1982-1984 and the EAB Accreditation 
Committee in 1984-87 while serving on 
the EAB board from 1979 to 1989. 

Rigas was born in Winnipeg, 
Manitoba, Canada. She received a BS 
in electrical engineering from Queen’s 
University in Canada and MSEE and 
PhD degrees from the University of 
Kansas. In 1983, she was awarded the 
Distinguished Engineering Service 
Award by the University of Kansas, the 
highest honor given to its engineering 
alumni. 

Survivors include her husband, 
Anthony, and a son, Marc. Anthony 
Rigas is director of the Lifelong Educa¬ 
tion Department in the College of 
Engineering at Michigan State and 
served as staff director of IEEE educa¬ 
tional activities in 1986-1987. 

Contributions can be made in Rigas’ 
name to the Michigan State University 
Development Fund for Graduate and 
Undergraduate Women in Electrical 
Engineering, Suite 220, 4700 Hagadorn 
Road, East Lansing, MI 48823. 


Researchers from varied backgrounds represented in MVL TC 

Dan A. Simovici, Chair, Technical Committee on Multiple-Valued Logic 


The IEEE Computer Society’s Tech¬ 
nical Committee on Multiple-Valued 
Logic is an interdisciplinary group that 
brings together people with varied 
interests in the development of both the 
basic research and the applied aspects 
of multiple-valued logic. Among the 
nearly 700 members of the TC are 
engineers interested in electronical and 
optical computing, computer scientists, 
mathematicians, and philosophers. 

The TC was established in 1980, with 
Jon T. Butler, a well-known researcher 
in a variety of areas of MVL, serving as 
founding chair. Its mission has always 
been to promote interest in multiple¬ 
valued logic and to help foster the 
exchange of research results and col¬ 
laborative research efforts. 

The TC’s main activity involves spon¬ 
soring the annual International Sympo¬ 
sium on Multiple-Valued Logic. 
Organized for the first time in 1970, this 
symposium will mark its 20th anniver¬ 


sary May 23-25, 1990, at the University 
of North Carolina at Charlotte. 

George Epstein of the University of 
North Carolina’s Department of Com¬ 
puter Science is the general chair. He 
will be happy to supply information to 
anyone interested in submitting a paper 
or attending the symposium. 

The event usually has three program 
co-chairs (one for the Americas, 
another for Asia and Australia, and a 
third for Europe and Africa). The 
accepted papers undergo a rigorous 
review process (usually involving three 
or four reviewers) to insure that the 
symposia are informative and worth 
attending. The range of topics includes 
algebraic and formal aspects, circuit 
and device implementations, fault 
detection and diagnosis, logic design 
and switching theory, probabilistic and 
variable-valued systems, high-speed 
computation, optical computing, fuzzy 
logic, and philosophical aspects. The 


proceedings are customarily published 
by the Computer Society Press. 

The symposia have been organized in 
a variety of countries: the US, Spain, 
Japan, Canada, and France. This year’s 
19th edition was held May 29-31 in 
Guangzhou, China. 

Many of the research endeavors of 
our members have an international 
character. Frequently, for example, 
authors from the US and Canada or 
from the US and Holland will col¬ 
laborate to write research papers. 

In addition, members of the TC have 
been active in organizing workshops 
that focus on specialized areas with a 
narrower scope. Two such workshops 
on spectral methods were held a few 
years ago. 

To stimulate the interest of IEEE 
members in multiple-valued logic, mem¬ 
bers of the TC have contributed to spe¬ 
cial issues of IEEE Transactions on 
Computers and to issues of Computer 
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dedicated to multiple-valued logic. 

The TC publishes a newsletter, and 
George Epstein is the current editor. 

A recent initiative, suggested by K.C. 
Smith of the University of Toronto, 
concerns establishing a bibliographical 
database in multivalued logic. The 


intended repository of this database is 
the University of Massachusetts in Bos¬ 
ton. I will be grateful for any bib¬ 
liographical contributions (submitted 
through electronic mail or through any 
magnetic support: floppy disk or tape). 
This database will be freely accessible to 
anybody interested in MVL. 


For further information on the activi¬ 
ties of the TC on Multiple-Valued 
Logic, contact Dan A. Simovici, 
Department of Mathematics and Com¬ 
puter Science, University of Mas¬ 
sachusetts at Boston, Boston, MA 
02125, phone (617) 929-7966, electronic 
mail (CSNet) dsim@umb.edu. 


NEWS FROM THE COMMITTEE ON PUBLIC POLICY 

Computer security practitioner certification plan 


Ralph J. Preiss, COPP Chair 

“COPP believes that certification of 
developers of critical-mission software 
needs a penetrating review and a IEEE 
Computer Society position,” according 
to Paul I. Davis, COPP vice chair. 
“Computer software is becoming so 
pervasive in our daily proceedings, and 
it is inconspicuous to the public. A 
majority of the public is thought to be 
unaware of the possible catastrophic sit¬ 
uations that could occur when software 
fails to carry out its mission.” 

Specialty certification was a major 
topic at the 1988 workshop of the IEEE 
Professional Activities Committee for 
Engineers in Phoenix, Arizona, in Sep¬ 
tember 1988, Davis said. “But,” he 
added, “a large majority of attendees 
opposed certification.” In fact, the 
Computer Society Board of Governors 
has a standing position, since Novem¬ 
ber 1982, opposing any action by the 
Institute for Certification of Computer 
Professionals (ICCP) to establish a cer¬ 
tification program for software 
engineering. 

This article reviews the work and plan 
of the International Information Sys¬ 
tems Security Certification Consortium 
to prepare for the professional certifica¬ 
tion of computer security professionals 
beginning in September 1991. 


Program warranted. In an article by 
Philip M. Fites, the May/June 1989 edi¬ 
tion of the Computer Security Newslet¬ 
ter reported that information security 
has matured sufficiently as a profession 
to warrant a full-fledged certification 
program that accurately measures an 
individual’s competence. It added that a 
widely accepted certification program 
would add credibility and prestige to the 
entire information security community. 

The Information Systems Security 
Association began a process of creating 
a program for certification of profes¬ 
sional practitioners in information sys¬ 
tem security as early as 1986. In 1987 


and 1988, the National Security Agency 
sponsored two workshops—one at the 
University of Maryland and the other at 
Idaho State University—that created a 
number of modules intended for use by 
universities in teaching computer secu¬ 
rity in engineering and in business 
programs. 

Then, in November 1988, the Special 
Interest Group for Computer Security 
of the Data Processing Management 
Association (DPMA) brought together 
a consortium of organizations to sup¬ 
port the creation of a professional cer¬ 
tification program with a target of 
having the first formal certification 
examination by September of 1991. 

The International Information Sys¬ 
tems Security Certification Consortium 
is a nonprofit society whose funding is 
directed towards the creation and 
administration of the examination and 
certification processes. In view of the 
ever-changing technology, the plan is to 
keep the certification process current, 
and certified individuals will have to 
demonstrate their competence through 
study and reexamination on a periodic 
basis. 

In fact, those information security 
professionals who will be involved in 
creating the first exam (and thereby 
qualify under a grandfather clause) will 
one day have to take the exam created 
by other “certified” professionals. 

Active participants in the consortium 
include the DPMA, Idaho State Univer¬ 
sity, the National Security Agency, and 
the Computer Security Institute. 
According to Richard C. Koenig, 
associate director of the Computer 
Security Institute, interest has been 
shown by agencies of both the Cana¬ 
dian and US governments, as well as by 
members of IFIPS and the Canadian 
Information Processing Society, to par¬ 
ticipate in the certification process. At 
this time, other societies are being 
informed of the plan, including the 
IEEE Computer Society. 


This report of the IEEE Computer 
Society Committee on Public Policy 
has not been approved by the IEEE 
Computer Society Board of Gover¬ 
nors and does not represent the offi¬ 
cial position of the Computer 
Society. 


Formal document. The task and plan 
were outlined in a formal document 
issued by the consortium in June 1989. 

It stated that any program to license 
professionals must include a code of 
ethics, codes of conduct and good prac¬ 
tice, a defined body of knowledge, a 
uniform examination and certification, 
an apprenticeship or intern program, an 
accredited higher education program, a 
continuing education requirement 
and/or a recertification procedure, an 
oversight by society (namely laws), and 
an image in the mind of the public. 

It went on to state that the Computer 
Security Curriculum Modules developed 
under the auspices of the National Secu¬ 
rity Agency address the issues of an 
accredited education program, and this 
work has also supported the common 
body of knowledge that will be main¬ 
tained in a data bank at Idaho State 
University. 

The code of ethics and code of con¬ 
duct and guidelines for good practice 
are under development. They are based 
on the codes of organizations that 
already have such guidelines, such as 
the British Computer Society, the Cana¬ 
dian Information Processing Society, 
DPMA, Information Systems Security 
Association, and others. 

Creation of a database of test ques¬ 
tions (with justified answers) creating 
and validating the test initially and 
monitoring the test as it matures over 
the years is a formidable task still to be 
undertaken. A testing service RFP is 
planned to be released in December 
1989, and a testing service will be in 
place by February 1990. The first test is 
expected to be evaluated in June 1991 
and the administered in September 
1991. 

The Committee on Public Policy of 
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the Computer Society is interested in 
the ethics, the security and privacy laws, 
and the public image of computer 
professionals. The problem that needs 
to be addressed by the Computer Soci¬ 


ety is whether certification of computer 
security practitioners is the answer. 

The consortium has been formed 
because the founding members feel a 
need for it. For more information on 


the consortium, or to become involved, 
you are urged to contact Michael J. 
Corby, M. Corby Associates, PO Box 
98, Spenser, MA 01562-0098, phone 
(508) 885-6994. 


Board of Governors proposes bylaws amendments dealing with elections 


At its May 19 meeting in Pittsburgh, 
the IEEE Computer Society Board of 
Governors passed three amendments to 
the society’s bylaws for the first time. 
All three relate to the nomination and 
election process. 

The changes were recommended to 
the board by the Constitution and 
Bylaws Committee, chaired by 
President-elect Helen M. Wood. They 
are published here for member com¬ 
ment in anticipation of their consider¬ 
ation for the second time at the 
November 17 board meeting in Reno. 

Member comments are solicited and 
should be sent to Helen M. Wood, 
Chair, Constitution and Bylaws Com¬ 
mittee, IEEE Computer Society, 1730 
Massachusetts Ave. NW, Washington, 
DC 20036-1903. 

The constitution was amended in 
1987 to provide for the annual election 
of fewer governors (seven instead of 10) 
and longer board terms (three years 
instead of two). 

To complete those amendments, two 
implementing changes are required in 
the bylaws that will have the effect of 
maintaining a consistent policy intent. 

When 10 governors were elected each 
year, the bylaws required that a mini¬ 
mum of 50 percent more candidates (15 
total) be nominated. This assured that 
the membership had adequate choices. 
With only seven governors elected each 
year, continuation of 15 minimum 
nominees insures that the number of 
candidates not elected will exceed the 
number who are elected. Accordingly, 
the Board of Governors approved a 
bylaw amendment that would keep the 
approximate 50 percent ratio, reducing 
the minimum number of nominees from 
15 to 11. 

Article II. Nominations and Elections 
Section 1. Nomination to the Board of 
Governors 

Current wording: The Board shall 
select by secret ballot not less than 15 
nominees to fill elected Board members 
positions, and the names of those 
nominees shall be published in a Society 
publication nominally reaching the 


entire membership sufficiently in 
advance of the deadline for receipt of 
petitions to allow a reasonable time to 
obtain necessary signatures. 

Proposed wording: The Board shall 
select by secret ballot not less than 11 
nominees to fill elected Board members 
positions, and the names of those 
nominees shall be published in a Society 
publication nominally reaching the 
entire membership sufficiently in 
advance of the deadline for receipt of 
petitions to allow a reasonable time to 
obtain necessary signatures. 

The second change derivative of the 
1987 constitutional amendment was 
intended to retain the six-year limit on 
consecutive service on the Board of 
Governors. The previous limit was three 
two-year terms. When the terms were 
increased to three years, the limit effec¬ 
tively increased by 50 percent to nine 
years. The proposed amendment would 
reduce the number of consecutive terms 
a Board member may serve from three 
to two, thus restoring the six-year limit. 

Article II, Nominations and Elections 
Section 3. Board of Governors Qualifi¬ 
cation 

Current wording: (3) A Board mem¬ 
ber may not seek a fourth consecutive 
term. For this purpose, the occupying 
of a Board position for a period of less 
than six months shall not be construed 
as holding that position. 

Proposed wording: (3) A Board 
member may not seek a third consecu¬ 
tive term. For this purpose, the occupy¬ 
ing of a Board position for a period of 
less than six months shall not be con¬ 
strued as holding that position. 

Recognizing that current petition 
requirements for governor and officer 
nominations were established when the 
society was much smaller, the board 
raised those requirements by amending 
the bylaws. Higher limits were consid¬ 
ered, but the board wanted to remain 
sensitive to the need to keep the society 


open to direct participation by the 
membership in setting directions and 
choosing its leaders. The following 
sections are to be amended: 

Article II. Nominations and Elections 
Section 1. Nomination to the Board of 
Governors 

Current wording: Additional 
nominees may be named by signature of 
at least 50 voting members of the Soci¬ 
ety with each member eligible to sign 
only one petition. 

Proposed wording: Additional 
nominees may be named by signature of 
at least 250 voting members of the Soci¬ 
ety with each member eligible to sign 
only one petition. 

Section 5: Officer Nominations 

Current wording: Additional 
nominees may be named by signature of 
at least 250 voting members of the Soci¬ 
ety, with each member eligible to sign 
one petition for each office. 

Proposed wording: Additional 
nominees may be named by signature of 
at least 1,000 voting members of the 
Society, with each member eligible to 
sign one petition for each office. 


Eckert-Mauchly Award 
nominations sought 

Nominations for the ACM/IEEE 
Eckert-Mauchly Award, presented 
annually to an outstanding computer 
architect for significant contributions to 
computer architecture, are being 
solicited. 

The 1990 nominations may be in any 
form and should be submitted by 
October 1 to: G. Jack Lipovski, Chair, 
Eckert-Mauchly Award Committee, 
Department of Electrical and Computer 
Engineering, University of Texas, Aus¬ 
tin, TX 78712. 
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IEEE Computer Society Election 

Nominees for Computer Society office and Board of Governors 


On the following pages are the position statements and biographies of the Computer Society’s candidates for president-elect, first and second vice 
presidents, and Board of Governors. Within each category, candidates are listed in alphabetical order. 

Election of officers to one-year terms and of board members to three-year terms, each beginning January 1, 1990, will be by vote of the membership 
as specified in the bylaws. Ballots, which will be mailed to all society members about September 1, must be at IEEE Headquarters no later than Octo¬ 
ber 13, 1989. Election results will be announced in the December issue of Computer. 

The opinions expressed in the statements are those of the individual candidates and do not necessarily reflect Computer Society positions or policies. 


Nominees for president-elect 


Duncan H. Lawrie 

Position statement. A 
major challenge facing 
our profession is the ap¬ 
plication of computing 
power to the dissemina¬ 
tion of our periodicals 
and other publications. 

We must be able to disseminate all of our publi¬ 
cations in electronic form and make available 
powerful software for finding pertinent pa¬ 
pers, books, standards, and proceedings. The 
Computer Society must take a leading position 
in this effort. The technology is now available, 
and it is time to apply it to this problem. 

The IEEE has a pilot project using CD-ROM 
technology to catalog and contain all of its cur¬ 
rent periodicals. This is certainly a step in the 
right direction, but we must go much further. 
We need to be able to handle text, graphics, and 
pictorial data at the same time, and be able to 
use this information over networks, at our own 
desks, on our own workstations. We need to in¬ 
clude all our conference proceedings and stan¬ 
dards publications in the program. And we 
need Jpowerful search software to allow litera¬ 
ture searches and citation analyses — not just 


of our own publications, but over all publica¬ 
tions in our profession. 

Over the past year, we have been working to 
expand the publishing activities of the Com¬ 
puter Society Press. While the main function of 
the CS Press has been to publish proceedings 
and tutorials, I feel it can fulfill a much larger 
function for our members. For example, we 
have so many journals today that it is becoming 
impossible to keep up in any area but our own. 
So the press is publishing focused reprint se¬ 
ries with papers chosen by experts as the most 
relevant in a given area. We are also beginning 
to publish monographs and other books. And 
we are now making high-quality video mate¬ 
rial available to our members. 

Our conferences and tutorials programs are 
another important aspect of the services pro¬ 
vided to our members. I will continue working 
to improve the quality and relevance of our 
conferences and tutorials by encouraging 
higher standards for speaker presentations and 
by continuing to encourage a closer relation¬ 
ship between conferences and our technical 
committees. 

Biography. Lawrie is vice president for the 
Computer Society Press and a member of the 
Board of Governors. He has served on the Pub¬ 


lications Board as acting vice president and 
chair of the Transactions Advisory Committee, 
and on the Conferences and Tutorials Board. 

He was program cochair of the International 
Conference on Parallel Processing, general 
chair of the International Conference on Dis¬ 
tributed Computing Systems, an editor of 
Communications of the ACM , and is currently 
an editor of the new IEEE Transactions on Par¬ 
allel and Distributed Systems. 

A professor of computer science and electri¬ 
cal and computer engineering, Lawrie is also 
associate director of the Center for Supercom¬ 
puting Research and Development at the Uni¬ 
versity of Illinois. He contributed to the design 
of the IUiac IV and the Burroughs Scientific 
Processor and is currently working on the Ce¬ 
dar large-scale multiprocessor. He has a strong 
interest in public policy issues and has served 
on advisory panels for DoE, NSF, NRC, and 
SIAM. He is currently a member of the Scien¬ 
tific Supercomputing Subcommittee of IEEE- 
USAB. 

Lawrie received a BA from DePauw Univer¬ 
sity, a BSEE from Purdue University, and MS 
and PhD degrees from the University of Illi¬ 
nois. He is a fellow of the IEEE. 



Joseph E. Urban 

Position statement. The 
Computer Society is 
flourishing. Member 
services such as confer¬ 
ences, publications, 
standards, and technical 
committees are growing. 
Our publications and technical meetings con¬ 
tinue to be high-quality, effective means for 
disseminating advances in technology. Stan¬ 
dards activities, now at a peak, are a driving 
force in the field. We can expand our activities 
by planning more carefully for better delivery 
of services without putting a strain on members. 

My goals are to 

(1) provide growth and improvement in the 
publications area — especially Computer 
magazine, where members support innovative 
ideas; 

(2) expand the tutorials program and provide 


other continuing-education mechanisms; 

(3) increase grass-roots activities of chap¬ 
ters, standards working groups, and technical 
committees; 

(4) explore additional means for delivery of 
technical material (for example, audio- and 
videotape) in addition to traditional print me¬ 
dia, while enhancing access and handling; and 

(5) structure the Computer Society staff 
to provide increased and better service for 
members. 

Advances in computing directly impact us in 
our jobs and our professional society. It is im¬ 
portant that we maintain and expand the soci¬ 
ety’s solid technical leadership role. As in the 
past, I will work to promote technical activities 
inside and outside the US through conferences, 
visiting lecturers, model curricula, networks, 
and society offices. Volunteer recognition is 
critical to this whole process. In addition, I will 
work to enhance intersociety activities 
through affiliate agreements, cosponsorship, 
cooperation, and exchange programs. 


I am a strong advocate not only for technical 
activities but also for the financial health of the 
society. As treasurer (1986-87) I managed the 
society’s finances during a slump in the com¬ 
puter industry and succeeded in restoring a 
sound financial base. 

I have served the Computer Society for a 
decade. My recent experience includes the 
Board of Governors, the Executive Commit¬ 
tee, the Conferences and Tutorials Board, the 
Operations Committee, and the Personnel and 
Compensation Committee. I have also partici¬ 
pated on the Area Activities, Publications, and 
Technical Activities Boards. This vision and 
experience will enable me to work with mem¬ 
bers, volunteers, and staff. I welcome your sup¬ 
port and ideas to help the Computer Society 
continue to evolve as an organization that ef¬ 
fectively meets your needs. 

Biography. Urban, the Computer Society’s 
first vice president, responsible for confer¬ 
ences and tutorials, is general chair for the 
Sixth International Conference on Data Engi- 
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neering. He served on the Board of Governors 
and the Executive Committee, and was treas¬ 
urer and Finance Committee chair. 

He initiated and chaired the Computer Lan¬ 
guages Technical Committee and chaired the 
Publications Planning Committee. He chaired 
and lectured in the Chapter Tutorials and Dis¬ 
tinguished Visitors Programs. He chaired four 
society conferences and served as an editor of 
IEEE Transactions on Software Engineering 


and IEEE Expert. 

Urban is professor of computer science in 
the College of Engineering and Applied Sci¬ 
ences at Arizona State University. He worked 
at the University of Miami, the University of 
Southwestern Louisiana, the US Army Signal 
Center, and the University of South Carolina 
(part-time). Recently he conducted research 
for Bell-Northern Research and Lockheed, and 
served on the US Air Force Studies Board. His 


research areas include software engineering, 
computer languages, and data engineering. 

He earned a BS from the Florida Institute of 
Technology, an MS from the University of 
Iowa, and a PhD from the University of South¬ 
western Louisiana, all in computer science. He 
received the Computer Society Meritorious 
and Distinguished Service Awards and an 
ACM Doctoral Forum Award. 


Nominees for first vice president 


Barry W. Johnson 

Position statement. The 
Computer Society’s pur¬ 
poses are to advance the 
theory, practice, and ap¬ 
plication of computer 
and information pro¬ 
cessing technology and 
to promote the exchange of technical informa¬ 
tion among its members. Fulfilling these pur¬ 
poses requires, in my opinion, four items: (1) 
excellent sources of technical information and 
innovation, (2) varied and high-quality mem¬ 
bership services, (3) financial stability, and (4) 
visibility of our activities. Having served as the 
society’s treasurer, vice president for Mem¬ 
bership and Information Activities, a member 
of the Conferences and Tutorials Board, and a 
member of the Technical Activities Board, 1 
feel 1 have the experience to help the society in 
these four closely coupled areas. 

We must continue to seek new and better 
services — for example, publications, confer¬ 
ences, and standards — that fulfill the needs of 
members. More important, perhaps, is ensur¬ 


ing the technical quality of existing programs. 
By working to maintain technical quality and 
controlled expansion of services, I feel we can 
better serve the membership. 

The Computer Society must also be fiscally 
sound to successfully continue its activities. I 
feel that maintaining a strong financial posi¬ 
tion is one of the most important problems fac¬ 
ing the society. We must plan for the financial 
cycles in the computer industry so that we can 
maintain a consistent level of funding for our 
important activities. 

Finally, society activities need visibility 
among both the membership and the general 
profession. I will continue to support enhanced 
promotional efforts for recruiting new mem¬ 
bers, keeping existing members, enhancing 
student activities, and increasing the general 
awareness of society activities within the com¬ 
puter profession. 

Biography. Johnson, the Computer Society’s 
vice president for Membership and Informa¬ 
tion Activities, has been active in the society 
since 1985. He has served on the Conferences 
and Tutorials Board, the Technical Activities 
Board, the Membership and Information Ac¬ 



tivities Board, as chair of the Membership De¬ 
velopment Committee, as chair of the Finance 
Committee, as an associate editor of IEEE 
Micro, and as treasurer. 

He is an associate professor of electrical en¬ 
gineering and a member of the Center for Semi¬ 
custom Integrated Systems at the University of 
Virginia. Before joining the university, he 
worked for the Government Aerospace Sys¬ 
tems Division of Harris Corporation. His inter¬ 
ests include fault-tolerant computing, testing, 
and VLSI. He has authored a textbook entitled 
The Design and Analysis of Fault-Tolerant 
Digital Systems from Addison-Wesley. 

Johnson received PhD, ME, and BS degrees 
in electrical engineering from the University 
of Virginias He has received several Computer 
Society award certificates, an award for out¬ 
standing contributions from the Virginia 
Chapter of Eta Kappa Nu, an outstanding 
young faculty member award from the Depart¬ 
ment of Electrical Engineering, and the 1989 
University of Virginia Alumni Association 
Young Teacher Award. A member of the IEEE, 
Johnson also belongs to the Industrial Elec¬ 
tronics Society, Tau Beta Pi, Eta Kappa Nu, 
and Sigma Xi. 


Laurel V. Kaleda 

Position statement. The 
Computer Society has 
benefited from steady 
growth in membership 
and activities during re¬ 
cent years. This growth 
reflects the value of ser¬ 
vices the society provides, especially those 
that blend theory and practice. 

The society’s increasing size, complexity, 
and diversity require that its leaders work to 
ensure effective society operations while sup¬ 
porting continued expansion and enhancement 
of services to members. This challenge of com¬ 
bining efficient operations with expansion is 
compounded by the rapid advancement of 
computer technology and today’s fast-moving 
economic climate. 

We need to sustain the society’s current 
growth and continue improving member ser¬ 
vices by focusing on three specific actions: 

(1) Reassessing all activities regularly so 
that we understand the value-Of each and focus 
our efforts on those that are good, timely, and 


that signal new opportunities. 

(2) Improving communication with mem¬ 
bers about society activities and state-of-the- 
art hardware and software. 

(3) Continuing to increase the number of 
members personally and directly involved 
with society activities. 

As vice president I worked with the Techni¬ 
cal Activities Board to develop TABS as a new 
means of communication. We also developed 
new activities using task forces, and new meth¬ 
ods such as the interdisciplinary satellite sym¬ 
posium, Compusat. 

We must strengthen the society today so that 
it can effectively serve members tomorrow and 
in the twenty-first century. The challenge is to 
plan for changes now so that we will be finan¬ 
cially and organizationally able to lead with 
new capabilities, rather than just react. 

I look forward to working with the society on 
these challenges. 

Biography. Kaleda is the Computer Society’s 
second vice president for technical activities. 
She is active on the Membership and Informa¬ 
tion Activities Board and has served on the Fi¬ 
nance and Audit Committees. She chaired the 



society's Standards Coordinating Committee; 
was program cochair for CompStan 88, the 
Conference on Computer Standards; served on 
several program committees; and organized 
and chaired a number of panel sessions in the 
standards area. She was awarded a Computer 
Society Meritorious Service Award (1987) for I 

her excellence in leadership and support of the 
society’s standards activities. 

Kaleda is a member of the Storage Systems 
Strategy Department for IBM’s General Prod- 1 

ucts Division (GPD), San Jose, California. She 
works with both hardware and software devel¬ 
opers to search out new opportunities for im¬ 
proving IBM products. 

She was previously division standards au¬ 
thority for IBM GPD. Her 21 years with IBM 
have provided experience on a wide range of 
computers (from PCs to 3090s) and software 
(operating systems through applications). 

Kaleda has a BS in applied mathematics and 
computer science from Washington Univer¬ 
sity, St. Louis, and an MBA from Golden Gate 
University, San Francisco. She is a licensed 
professional engineer in California, a senior 
member of IEEE, and a member of ACM. 


COMPUTER 



















Nominees for second vice president 


Paul L. Borrill 

Position statement. The 
Computer Society goes 
from strength to 
strength. This, I believe, 
is due directly to (1) the 
responsiveness and qual¬ 
ity of service we provide 
to meet the needs and desires of our members 
with publications, conferences, and tutorials, 
and (2) the encouragement we provide for 
membership involvement in our technical and 
standards activities. My interpretation of 
members’ needs, based simply on my own 
needs as a professional, indicates that we must 
provide an environment in which to help the in¬ 
dustry, continue our education, and nurture 
and develop our creativity, style, and profes¬ 
sionalism in the most positive way possible. 

As a great believer in open industry stan¬ 
dards, I am especially interested in continued 
improvement in our standards development 
process. The time has come to match the cele¬ 
brated technical creativity and innovation 
shown so often in our standards activities with 
sound management and administrative prin¬ 
ciples, so that we can assure the industry that 
standards can be developed in the IEEE Com¬ 
puter Society as quickly and effectively as the 
industry requires. 


Biography. Borrill is the Computer Society’s 
vice president for standards and a member of 
the Board of Governors. First elected to the 
board as a petition candidate in 1984, he has 
served at all levels: as the society’s first om¬ 
budsman (a function he initiated over his con¬ 
cern for responsiveness to members), as secre¬ 
tary of the Board of Governors, and as chair of 
many standards working groups, including the 
innovative and now highly successful Future - 
bus+ Working Group. He also serves as the 
Computer Society’s representative to the IEEE 
Standards Board and is a member of Nescom, 
its New Standards Subcommittee. 

Borrill recently joined Sun Microsystems as 
a distinguished engineer. He was previously 
staff scientist responsible for development of 
the multiprocessing strategy for National 
Semiconductor. 

He received his BSc in physics (with honors) 
from the University of Manchester and his PhD 
in physics from University College London. A 
member of IEEE and ACM, he is a chartered 
engineer (C.Eng.) with the Institution of Elec¬ 
trical Engineers in the UK. Borrill received 
NASA’s Public Service Group Achievement 
Award and the Computer Society’s Meritori¬ 
ous Service and Outstanding Contribution 
Awards. 



Bill D. Carroll 

Position statement. I am 
proud to have been in¬ 
volved with the Com¬ 
puter Society for more 
than 15 years in a variety 
of areas including educa¬ 
tion, publications, area 
activities, and conferences. If elected second 
vice president, I pledge to use my experience 
and skills to further society development in 
these and other areas. 

In particular, I will work to strengthen the 
society’s programs in education and related 
areas. I feel there is a need to revise the 1983 
Computer Science and Engineering Model 
Program to address the impact of new technol¬ 
ogy not only on curriculum content but also on 
program structure and delivery methods. Fur¬ 
thermore, I believe the Computer Society 
should take an active role in the development of 
models for masters-level and continuing- 
education programs. Also, I pledge to continue 
strong support for accreditation activities as¬ 
sociated with the Accreditation Board for En¬ 
gineering and Technology and the Computer 
Science Accreditation Board. In addition, I 
will seek means to provide increased support 
for the Computing Research Board and for the 
Association for Computer Science and Engi¬ 
neering Chairs. Moreover, I will strive to es¬ 
tablish programs jointly with other boards and 
organizations to attract more students to the so¬ 
ciety and the profession. I will also work to at¬ 
tract new, active volunteers to the society. 


Finally, I recognize the need to operate the 
Computer Society on sound financial footing. 
Hence, I will support fiscal policies that will al¬ 
low the society to develop necessary new ser¬ 
vices and products while maintaining adequate 
reserves and affordable dues. 

Biography. Carroll is a member of the Com¬ 
puter Society’s Board of Governors, the Edu¬ 
cational Activities Board, and the IEEE 
Committee on Engineering Accreditation Ac¬ 
tivities. His earlier activities include service as 
editor-in-chief of the Computer Society Press, 
member of the Computer Science and Engi¬ 
neering Model Program Task Force, South¬ 
eastern Area chair, and founding chair of the 
Alabama Chapter. He was also a founding 
member of the Association of Computer Sci¬ 
ence and Computer Engineering Chairs. 

A professor at the University of Texas at Ar¬ 
lington since 1981, Carroll is also chair of the 
university’s Computer Science Engineering 
Department. Previously, he served on the Au¬ 
burn University faculty, held a visiting ap¬ 
pointment at the University of California, 
Berkeley, and was an engineer at Texas Instru¬ 
ments and General Dynamics. He has authored 
numerous papers and reports on fault-tolerant 
computing, computer-aided design, and engi¬ 
neering education. He is coauthor of two 
books, An Introduction to Computer Logic 
(Prentice-Hall, 1975) and Fault-Tolerant 
Computing (Computer Society Press, 1987). 
He received a PhD in electrical engineering 
from the University of Texas at Austin in 1969. 
He is an IEEE fellow and a member of several 
professional and honor societies. 



Nominees for 
Board of Governors 
(16 nominees; vote for 7) 


Jon T. Butler 

Position statement. The 
primary challenge fac¬ 
ing the Computer Soci¬ 
ety is the delivery of 
services essential to the 
professional develop¬ 
ment of its members. In 
the past, these services have included confer¬ 
ences, workshops, magazines, and journals. 
Future services will also include satellite sym¬ 
posia, videotapes and videodiscs, and net- 

I believe the Computer Society's contribu¬ 
tion requires both new initiatives to implement 
future services and an adherence to high stan¬ 
dards in traditional services such as our maga¬ 
zines and journals. We must nurture emerging 
technologies with appropriate technical com¬ 
mittees, providing workshops, conferences, 
and newsletters. We must expand our tutorial 
series to include maturing fields. 

As a member of the Board of Governors, I 
will devote my energies to these goals, consis¬ 
tent with prudent use of our resources. 

Biography. Butler has been active in the Com¬ 
puter Society since 1980. He served as chair of 
the Multiple-Valued Logic Technical Com¬ 
mittee, vice-chair for hardware of the Techni¬ 
cal Activities Board, member of the Distin¬ 
guished Visitors Program, and on the Editorial 
Boards of IEEE Transactions on Computers, 
Computer magazine, and the Computer Soci¬ 
ety Press. 

Since 1987 he has been a professor in the De¬ 
partment of Electrical and Computer Engi¬ 
neering at the Naval Postgraduate School in 
Monterey, California. He has served as the 
NAVALEX Chair Professor at the Naval Post¬ 
graduate School and on the faculty at North¬ 
western University. He has held summer posi¬ 
tions in various companies including Bell 
Telephone Laboratories in Naperville, Illinois. 

Butler received a PhD in electrical engineer¬ 
ing from Ohio State University in 1973 and 
BEE and M.Engr. degrees from Rensselaer 
Polytechnic Institute in 1966 and 1967, respec¬ 
tively. He has been awarded the Meritorious 
Service Award and Certificate of Appreciation 
from the Computer Society, and he received 
the Outstanding Contributed Paper Award and 
the Award for Excellence from the Multiple- 
Valued Logic Technical Committee, for tech¬ 
nical papers. He has been awarded two National 
Research Council Postdoctoral Associateships 
and is a fellow of the IEEE. 
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Alicja I. Ellis 

Position statement. Ac¬ 
tive in the IEEE and the 
Computer Society at the 
chapter, area, and board 
levels, I am familiar with 
the challenges facing our 
volunteer leaders. My 
background in industry and academia gives me 
a special interest in providing members with an 
environment fostering continuing education 
and professional growth. If elected, I will pur¬ 
sue the following: 

(1) Ensuring the best possible services and 
technical information tailored to the needs of 
all members, with emphasis on application- 
oriented information for practicing profes¬ 
sionals. 

(2) Increasing support and expanding pro¬ 
grams available to chapters. Promoting more 
contacts between chapters, sections, regions, 

(3) Strengthening and increasing member 
participation in society activities. 

(4) Promoting and strengthening industrial 
liaison activities, and expanding — at the chap¬ 
ter and area levels — relations between society 
members and their employers. 

(5) Fostering the society’s transnational 

I plan to continue the excellent initiatives of 
current and past board members and to origi¬ 
nate new activities that will enhance society 
membership. 

Biography. Ellis has been active in the Com¬ 
puter Society since 1982. Her involvement in¬ 
cludes chapter officer (1983-85), Membership 
Development Committee chair (1989), chair 
of the IEEE/ACM Symposia on Artificial In¬ 
telligence (1986-87), and committee member 
for the IEEE/ACM Symposium on Graphics 
Technologies (1988) and the Symposium on 
Neural Networks and Parallel Computing 
(1989). 

She served in area activities as Area 4 chair 
(1986-87), Chapter Tutorials and Video Pro¬ 
grams chair (1987-88), and newsletter editor 
(1989). The Computer Society recently recog¬ 
nized her contributions to revitalizing chapter 
activities by presenting her with the Meritori¬ 
ous Service Award. 

Ellis manages the training program and 
ASIC product validation at Honeywell’s Solid 
State Electronics Center in Minneapolis, Min¬ 
nesota. Before joining Honeywell, she was in¬ 
volved in theoretical nuclear physics research 
at the University of Minnesota: Oxford Uni¬ 
versity, England; and the Institute of Nuclear 
Physics in Krakow, Poland. 

A senior member of the IEEE, Ellis received 
an MS in physics (minor in chemistry and 
mathematics) from Silesian University in 1964 
and a PhD in theoretical nuclear physics from 
Jagellonian University, Krakow, Poland, in 
1972. She is the author or coauthor of more than 
30 publications related to nuclear physics, sili¬ 
con processing, and microelectronics CAD 
and CAM. 




Gerald L. Engel 

Position statement. It has 
been an honor to work 
with the Computer Soci¬ 
ety and its volunteers and 
staff for the past 10 years. 
I look forward to new op¬ 
portunities to be of ser¬ 
vice. I strongly endorse the efforts of the soci¬ 
ety to sponsor and support a diversity of profes¬ 
sional activities and programs, and will work to 
find ways to see that such activities can be ex¬ 
panded to firmly establish the Computer Soci¬ 
ety as the leading voice for the profession. 

As we approach the 1990s, it becomes in¬ 
creasingly important that the society expand 
its influence both in the US and internationally. 
Additional cooperative activities with our sis¬ 
ter societies should be initiated and actively 
pursued. Moreover, I will continue to work for 
increased membership and participation in so¬ 
ciety activities, especially among traditionally 
underrepresented populations in the profession. 


Biography. Engel is vice president for educa¬ 
tional activities of the Computer Society, as 
well as one of the Computer Society-appointed 
directors of the Computing Sciences Accredi¬ 
tation Board. He has held various positions on 
the Educational Activities Board and the Publi¬ 
cations Board. Along with his current society 
projects, he is chairing a National Science 
Foundation-sponsored invited workshop deal¬ 
ing with computer science at minority institu- 


Engel has been involved in numerous activi¬ 
ties serving the computing professions. He was 
an organizer of the National Educational Com¬ 
puting Conference and its first steering com¬ 
mittee chair, and he served as the first chair of 
the Computer Science Accreditation Commis¬ 
sion. He is currently a member of the IEEE Ac¬ 
creditation Board for Engineering and Tech¬ 
nology (ABET) Activities Committee as well 
as the IEEE Engineering Self-Assessment Pro¬ 
gram Committee. 

A professor of computer science and engi¬ 
neering at the University of Connecticut at 
Stamford, Engel previously held teaching and 
research positions at Christopher Newport 
College, Old Dominion University, and the 
Virginia Institute of Marine Science. 

He received a BS magna cum laude from 
Hampden-Sydney College, an MA from Lou¬ 
isiana State University, and a DEd in computer 
science from Pennsylvania State University. 
He is a senior member of IEEE and a member of 
ACM. 


Tadao Ichikawa 

Position statement. The 
Computer Society has 
made remarkable prog¬ 
ress in recent years. 

There are more mem¬ 
bers, more publications, 
and a wide range of pro¬ 
fessional activities. That’s very encouraging, 
but we’ll have to ensure that it doesn’t uninten¬ 
tionally result in a more hierarchical, less ac¬ 
cessible structure. 

The topics we focus on should not be chosen 
solely because they reflect majority interests. 
Individual members should always be encour¬ 
aged to initiate new activities. Cooperation and 
interaction on these new activities should not 
be limited to any particular section of the soci¬ 
ety. We need, therefore, to establish better rela¬ 
tionships between members and administra¬ 
tive officials in every branch of the society, re¬ 
gardless of position or geographical location. 

On the basis of my own experience, I will 
work toward providing simpler, more efficient 
means of communication designed to promote 
innovative contributions from individual 
members. This, I believe, will make the society 
more beneficial to everyone. 

Biography. Ichikawa has been active in pro¬ 
gram organization as a program committee 
member for the IEEE International Conference 
on Data Engineering and many other IEEE con¬ 
ferences, symposia, and workshops. In 1984 he 
organized the IEEE Visual Languages Work¬ 
shop and is currently serving as a member of the 
workshop steering committee. He also serves 
on the Asian Activities Committee and is on the 
Editorial Boards of IEEE Transactions on Soft¬ 
ware Engineering and IEEE Transactions on 
Knowledge and Data Engineering. At a ple¬ 
nary session of the 1990 ACM Annual Com¬ 
puter Science Conference, he will give a talk 
titled “Organizing the World Symphony Or¬ 
chestra in Computer Technology.’’ 

A professor of computer engineering at Hiro¬ 
shima University in Japan, Ichikawa is inter¬ 
ested in database systems, programming meth¬ 
odologies, and knowledge-based program¬ 
ming environments. He has published numer¬ 
ous books and papers, including a collection of 
nonacademic essays titled Viva Nippon!? — 
Ruminations on Japan's Cultural, Educa¬ 
tional, and Industrial Institutions. 

Ichikawa received his BE in 1962 and his 
doctor of engineering degree in 1971, both 
from Waseda University, Tokyo. He received 
the Best Paper Award from the IEICE-Japan in 
1980, as well as other awards, and is a fellow of 
the IEEE. 
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Ralph J. Preiss 


Michel Israel 

Position statement. I am 
a Computer Society 
member because I be¬ 
lieve knowledge has an 
intrinsic value. Further¬ 
more, as a professor and 
as a European, I believe 
very strongly that knowledge is to be shared. 
This requires a coherent organization and a 
precise idea of the goals the Computer Society 
must set for itself. The year 1992 signifies a 
united Europe. The Computer Society must, in 
my opinion, not only consolidate its actual role 
but also become an intermediary for activities 
throughout Europe. Therefore, several objec¬ 
tives must be discussed: 

(1) Links between technical committees and 
corresponding working groups of national 
societies. 

(2) Emphasis on European conferences such 
as ETC and EDAC. 

(3) Integration of European members for 
discussion and definition of standards. 

(4) A federal role for the Computer Society 
in terms of IEEE and national societies. 

(5) Resolving the question of openness to¬ 
ward Eastern European countries. 

To address these issues, the Brussels office 
must become the center'of European activities. 

Biography. Israel is the European Advisory 
Committee chair and the Region 8 Area Activi¬ 
ties chair. He served as chair of the Multiple- 
Valued Logic Technical Committee for 1987 
and 1988, for which he received a Certificate of 
Appreciation. He also received an Outstanding 
Paper Award from the committee. In addition, 
he has been given the Meritorious Service 
Award and Certificate of Appreciation from 
the Computer Society for chapter activities in 
Region 8. 

He is a member of the AFCET Board of Gov¬ 
ernors (the largest French society in computer 
science), chair of the AFCET design automa¬ 
tion group, and a member of the AFCET Com¬ 
puter Science Board. A full professor at the 
IIE-CNAM (an engineering school in com¬ 
puter sciences), he teaches computer organiza¬ 
tion, algorithmics, and graphics. He was a 
visiting professor for a year at the Electrical 
Engineering Department of the University of 
Toronto under a NATO scholarship. 

Israel’s research interests include multiple¬ 
valued-logic circuits and design automation 
tools. Currently he is working on design auto¬ 
mation tools in conjunction with the Philips 
Laboratories and IBM. He holds a Doctor of 
Science Thesis from the University of Paris. 



David Pessel 

Position statement. As a 
member of the Board of 
Governors, I will con¬ 
tinue to emphasize tech¬ 
nically strong and widely 
available membership 
services. I will strive to 
expand local, high-quality tutorials and meet¬ 
ings and to make them available at greatly re¬ 
duced cost. I will ensure that our large selection 
of publications meets the requirements of as 
broad a spectrum of members as possible in a 
cost-effective fashion. As I did with IEEE Ex¬ 
pert , I will continue to identify emerging areas 
of technology that deserve Computer Society 
attention. 

The Board of Governors has ultimate re¬ 
sponsibility for maintaining the financial as 
well as technical integrity of the Computer So¬ 
ciety. Our solid membership growth has had 
the dual effect of increased revenues and in¬ 
creased demands for service. I will work to en¬ 
sure that these are balanced to maintain the so¬ 
ciety’s sound financial footing. 

Biography. Pessel has served the Computer 
Society as editor-in-chief of IEEE Expert, chair 
of the Membership and Audit Committees, and 
member of the Magazine Advisory Commit¬ 
tee, the Publications Board, and the Education 
Board. He is completing his second nonconse- 
cutive term on the Board of Governors. 

Employed by BP America since 1980, Pessel 
is currently director of information sciences at 
the R&D center. Previously, he served on the 
UC Berkeley electrical engineering and com¬ 
puter sciences faculty and the University of 
Rochester electrical engineering and obstet¬ 
rics and gynecology faculty. He was manager 
of the Laser Computing Facility at Rochester. 

Pessel received his BS in system engineer¬ 
ing from Polytechnic University in 1969 and 
his MS and PhD degrees in electrical engineer¬ 
ing and computer sciences from the University 
of California, Berkeley, in 1970 and 1974, re¬ 
spectively. A member of AAAI, Sigma Xi, and 
Eta Kappa Nu, he has received a number of fel¬ 
lowships and awards during his career. 




Position statement. My 
20-plus years with the 
Computer Society’s 
Awards and Recognition 
Program has enabled me 
to meet many of the 
architects and movers of 


this information age. For almost 10 years I have 
helped create position statements on technol¬ 
ogy issues as a step toward public policy. I want 
to apply my talents to enhance public recogni¬ 
tion of computer professionals. I believe that 
when the public recognizes the contributions 
of computer professionals to our standard of 
living, they will be more willing to heed their 
counsel in matters of public policy. 

Members look to the Computer Society to 
keep them technologically abreast of the com¬ 
puting field through tutorials, workshops, con¬ 
ferences, and publications. I enjoy serving on 
committees to plan these educational opportu¬ 
nities. If elected, I will work to ensure that the 
society’s educational programs continue to be 
well balanced and of the highest quality, ser¬ 
ving not only young engineering graduates but 
also old-timers like myself. 


Biography. Preiss, a senior member of the 
IEEE, is chair of the Committee on Public Pol¬ 
icy and has been a member since its inception. 
He is working on position statements for copy¬ 
right protection, software vandalism, tax law 
reforms, foreign engineers, and software 

He served on the Design Automation Tech¬ 
nical Committee and helped originate the an¬ 
nual Design Automation Workshops. As com¬ 
puter group liaison to the IEEE Standards 
Board, he contributed to the first IEEE diction¬ 
ary, ASCII, and computer logic drafting- 
symbol standards. 

Preiss served on the Editorial Advisory 
Board of Computer magazine and on the steer¬ 
ing committee of the VLSI Test Workshops in 
Atlantic City, 1983-86. He was vice-chair of 
the 1985 IEEE Microprocessor Forum, cochair 
of the 1986 IEEE Workstation Technology and 
Systems Conference, and general chair of the 
1987 Workstation Technology and Systems 
Workshop. 

He has had a long career with IBM, where he 
received an IBM Outstanding Contribution 
Award. He is currently involved in reliability 
and serviceability studies. He has also received 
a Computer Society Meritorious Service 
Award and an IRE Prize Paper Award, and he is 
on the Computer Society Honor Roll. He holds 
a BSEE from MIT and an MS in engineering 
from the University of Connecticut. 
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Sallie V. Sheppard 

Position statement. The 
strength of the Computer 
Society comes from its 
ability to meet the needs 
of its members. The 
Computer Society is 
known worldwide for 
providing its members with forums for techni¬ 
cal information exchange through its sponsor¬ 
ship of publications and conferences. To con¬ 
tinue its leadership role, the Computer Society 
must adapt to new technologies for delivery of 
technical information. In addition to this type 
of service, I believe the Computer Society can 
offer members more opportunities for involve¬ 
ment in our profession through activity on edi¬ 
torial boards, technical committees, and stan¬ 
dards committees. 

As a member of the Board of Governors, I 
will continue to work to enhance Computer So¬ 
ciety vitality through increased membership 
involvement. This can provide many members 
with the opportunity to network with others of 
similar interests and thus influence the evolv¬ 
ing state of the art. 

Biography. Sheppard is a member of the Com¬ 
puter Society’s Board of Governors and vice 
president for publications. She has chaired the 
Magazine Advisory Committee and served on 
the Editorial Board of Computer magazine for 
two years, where she was editor of the Com¬ 
puter Society News Department. She has also 
been active with the Technical Activities 
Board, having served as vice-chair for publica¬ 
tions and communications and vice-chair for 
software. She has been both chair and vice¬ 
chair of the Technical Committee on Simula- 

Sheppard’s numerous roles at Computer So¬ 
ciety-sponsored conferences include serving 
as the 1984 Winter Simulation Conference 
Proceedings editor. She is currently the Com¬ 
puter Society representative to the Winter 
Simulation Conference Board. In addition to 
IEEE, Sheppard is a member of ACM and the 
Society for Computer Simulation. 

Currently associate provost for honors pro¬ 
grams and undergraduate studies and a profes¬ 
sor of computer science at Texas A&M Univer¬ 
sity, Sheppard is interested in simulation and 
AI support for software engineering. She was a 
Halliburton Professor in 1983 and received the 
Texas A&M Former Students Outstanding 
Teaching Award in 1985. She received a PhD 
in computer science in 1977. 



Bruce D. Shriver 

Position statement. The 
Computer Society is in 
the information busi¬ 
ness. Its journals, maga¬ 
zines, workshops, con¬ 
ferences, tutorials, and 
the Computer Society 
Press are all important information conduits. 
The Computer Society should not only provide 
traditional forums where research results can 
be presented and discussed, it should also be 
innovative in sponsoring activities for the in¬ 
formal sharing of the results of development 
efforts, experiments, and experiences. The fu¬ 
ture of the society largely depends on how suc¬ 
cessful we are in promoting and managing the 
flow of useful, timely information within our 
rapidly changing field. The numerous activi¬ 
ties and services we provide are all expensive 
in time, talent, and money. As a member of the 
Board of Governors, I will support cost-effec¬ 
tive methods to promote and manage our infor¬ 
mation business. 

Biography. Shriver, editor-in-chief of Com¬ 
puter magazine, has served the Computer Soci¬ 
ety in many capacities. Previously he was asso¬ 
ciate technical editor of Computer and the first 
editor-in-chief of IEEE Software. He is on the 
Computer Society’s Board of Governors, the 
Publications Board, and the Magazine Advi¬ 
sory Committee. He is a past chair of the Tech¬ 
nical Committee on Microprogramming and a 
past vice-chair of the Technical Committee on 
Computational Medicine. He has been either 
general chair or program chair for more than a 
dozen national and international conferences, 
as well as an IEEE distinguished visitor. 

Shriver is currently vice president for re¬ 
search at the University of Southwestern Lou¬ 
isiana in Lafayette. He was a research staff 
member and the department group manager of 
software technology at IBM’s T.J. Watson Re¬ 
search Center in Yorktown Heights, New 
York. Before joining IBM in 1984, he was the 
Alfred Lamson Research Professor of Com¬ 
puter Science at the University of Southwest¬ 
ern Louisiana, where he had spent the previous 
11 years. He has published over 50 technical 
papers and chaired some 17 dissertation com¬ 
mittees. He received his PhD in computer sci¬ 
ence from the State University of New York at 
Buffalo in 1971. Shriver is a senior member of 
the IEEE. 



Charles B. Silio, Jr. 

Position statement. The 
Computer Society fos¬ 
ters professional devel¬ 
opment by providing 
mechanisms for commu¬ 
nication among those 
engaged in research, de¬ 
sign, development, education, application, or 
appreciation of computers. This is accom¬ 
plished through sponsorship of repository 
journals (the transactions), magazines, confer¬ 
ences, workshops, tutorials, standards, and 
other educational and technical activities. The 
Board of Governors oversees all of this activ¬ 
ity, determines funding levels, and sets priori¬ 
ties. As a member of the board, I will seek to 
serve the needs of all our members in a fiscally 
responsible manner, continue to support suc¬ 
cessful activities, and look for new opportuni¬ 
ties to increase member services. I will attempt 
to promote better communication, through 
which we learn new things that help us perform 
our jobs, advance in our profession, and better 
recognize and appreciate each others’ ideas, 
work, needs, and accomplishments. 

Biography. Silio is Computer Society treas¬ 
urer and chairs the Computer Services Advi¬ 
sory and Finance Committees. He chaired the 
East Coast Operations Committee (1986-88), 
the Computer Society Press Advisory Com¬ 
mittee (1988), the Technical Committee on 
Multiple-Valued Logic (1983-84), and the Ar¬ 
rangements Committees for CompCon Fall 
(1976-77), and has been program chair for the 
Americas of three International Symposia on 
Multiple-Valued Logic (1982, 1988, and 
1990). He served on the CompCon Fall Stand¬ 
ing Committee (1977-83), and the Computer — 
Society Operations Committee (1986-89). He 
is a member of the IEEE TAB Finance Commit¬ 
tee and the IEEE Press Editorial Board. 

An associate professor of electrical engi¬ 
neering at the University of Maryland, during 
1985-87 Silio was associate department chair 
for graduate studies. During 1983-84 he was an 
NRC associate in operations research at the 
Naval Postgraduate School, Monterey, Cali¬ 
fornia. He has been a consultant to the Army 
Materiel Systems Analysis Activity (1977-83) 
and the National Technological University 
(1982-89). His work is in computer engineer¬ 
ing, communication networks, and security. 

Silio earned BS, MS, and PhD degrees in 
electrical engineering at the University of 
Notre Dame in 1965, 1967, and 1970, respec¬ 
tively. He is a member of Eta Kappa Nu, Tau 
Beta Pi, and Sigma Xi. 
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Harold S. Stone 

I Position statement. I 
1 plan to focus activities 
two areas: publica- 
is and budgeting. My 
I objective is to have Com- 
| puter Society publica- 
ts stay abreast of the 
field. This can be done by adding new publica¬ 
tions and shifting the focus of present ones 
through a planned, evolutionary process. The 
society must explore new ways to publish by 
taking advantage of electronic dissemination 
as it becomes available. New ventures have to 
produce information at low member cost yet 
with a high enough revenue return to sustain 
the enterprise. 

In budgeting and finance the trend in recent 
years has been for income to grow slower than 
expenses. Some changes in the budgeting pro¬ 
cess itself will help bring the growth rates to¬ 
gether in the short term and will enable the soci¬ 
ety to enter the next decade in strong financial 


Biography. Stone, a fellow of the IEEE, has 
long been active in the Computer Society, hav¬ 
ing served as chair of the Computer Architec¬ 
ture Technical Committee, technical editor of 
Computer magazine, and a member of the 
Board of Governors. He was also active in the 
ACM, where he served as associate editor of 
the JACM. 

He is the manager of advanced architecture 
studies at IBM’s T.J. Watson Research Center 
in Yorktown Heights, New York. He has been a 
faculty member at the University of Massachu¬ 
setts and Stanford University and has held vis¬ 
iting faculty appointments at institutions 
throughout the world. He is the author, co¬ 
author, or editor of six textbooks and has pro¬ 
duced more than 60 technical publications. 

The series he produced as a consulting editor to 
Addison-Wesley, McGraw-Hill, and Univer¬ 
sity Microfilms contain more than 70 titles in 
all areas of computer science and engineering. 

Stone received a PhD in electrical engineer¬ 
ing in 1963 from the University of California at 
Berkeley. His research contributions have 
been primarily in computer architecture and 
digital systems design. 


Jacques Tiberghien 

Position statement. With 
its strongest growth out¬ 
side North America, the 
Computer Society is be¬ 
coming the planetary fo¬ 
rum for computer scien¬ 
tists and engineers. This 
gives our society global responsibility, which 
must be shared by all members. Nowhere 
should the society be perceived as a foreign or¬ 
ganization trying to supersede local societies. 
In Europe I have established friendly contacts 
on behalf of Presidents Parrish and Anderson 
with eight European societies that have goals 
similar to ours. This has resulted in five formal 
affiliation agreements, cooperation on confer¬ 
ences, and many new common members. 

It is now the responsibility of all members to 
increase the credibility of these efforts by 
electing governors from Region 8. If elected, I 
will do my utmost, both within the Board of 
Governors and through contacts with local so¬ 
cieties, to increase the Computer Society’s im¬ 
portance in Region 8 and to improve the ser¬ 
vices to members from this region. 

Biography. Tiberghien was first active in the 
Computer Society as chair of the European Ac¬ 
tivities Committee and is now presidential ad¬ 
viser for Region 8 activities. He was instru¬ 
mental in the growth of the European office and 
was awarded an IEEE Computer Society Cer¬ 
tificate of Appreciation for the role he played in 
its development. He organized CompEuro 88, 
the joint conference of the Computer Society 
and IEEE Region 8. He is also a director of 
EuroMicro and chairs the Committee on Infor¬ 
matics of the KVIV, the largest Belgian engi¬ 
neering society. 

A full professor on the engineering faculty 
of the VUB (Free University of Brussels), Ti¬ 
berghien teaches introductory courses in com¬ 
puter sciences and more specialized courses on 
computer architecture and computer networks. 
He is on the board of the supercomputer center 
common to the two universities in Brussels. He 
has consulted for several large organizations, 
authored a textbook and more than 40 scien¬ 
tific papers, and edited several proceedings. 

Tiberghien received his electrical engineer¬ 
ing degree from the Universite Libre de 
Bruxelles in 1969 and his PhD from the Vrije 
Universiteit Brussel in 1976. During sabbati¬ 
cals he visited at Dalhousie University in Nova 
Scotia and the University of California at 
Berkeley. 




Wing N. Toy 

Position statement. My 
industrial and academic 
experience have made 
le aware of the rapidly 
expanding information 
I age. This evolution is 
1 both challenging and re¬ 
warding. I would like the opportunity to pro¬ 
vide input, help set the direction, and partici¬ 
pate in achieving the Computer Society's 
goals. 

Helping to meet the continual need for a 
closer coupling between academia and indus¬ 
try is vital to the society’s growth. One major 
goal should be to strengthen this relationship 
through useful and relevant technical inter¬ 
change. I will work for more direct participa¬ 
tion from industry to enhance the Computer 
Society’s technical programs. 

Another major benefit — or potential prob¬ 
lem — is the diverse needs of society members. 
These needs are growing and ever changing. 
Responses must be dynamically attuned to the 
advances of computer technology in a timely 
fashion through activities sponsored by tech¬ 
nical committees. I will work to promote these 
Computer Society activities for the welfare of 
its members. 


Biography. Toy, an IEEE fellow, has served on 
Computer magazine’s Editorial Board (1983- 
86), as an associate technical editor of IEEE 
Transactions on Computers (1986-88), as a 
member of the Board of Governors (1985-86), 
on the IEEE Ad Hoc Accreditation Visitors 
Committee (1979-84), and as program chair of 
Compsac 88. He received the IEEE Computer 
Society Meritorious Service Award (1984) and 
the Certificate of Appreciation (1987). 

Toy is a supervisor in the Advanced Switch¬ 
ing Networks Department at AT&T Bell Labo¬ 
ratories in Naperville, Illinois, where he has 
been involved in the design of highly reliable 
processors for telecommunication applications 
for 36 years. During the 1973-74 academic 
year, he was on the faculty of the Computer Sci¬ 
ence Division of the Electrical Engineering 
Department at the University of California, 
Berkeley, as a Visiting MacKay Lecturer. He 
was a consultant to the US Air Force on elec¬ 
tronic engine control (1979-82). He holds 27 
US patents and has published 20 technical pa¬ 
pers. He is coauthor of three textbooks on 
computer technology. 

Toy received his BSEE and MSEE from the 
University of Illinois and his PhD in electrical 
engineering from the University of Pennsylva¬ 
nia. He was named an AT&T Bell Labs fellow 
in 1983. 
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Anneliese von 
Mayrhauser 

Position statement. A 
professional society fa¬ 
cilitates development 
and transfer of new in¬ 
sights and technology 
through people, events, 
and publications. If elected, I will address the 
following concerns: 

(1) Innovative new services can expand the 
Computer Society’s basis without diluting its 
level of technical knowledge. For example, 
new presentation media may increase access to 
technical information around the globe. 

(2) Opening of the Tokyo and Brussels of¬ 
fices emphasizes the Computer Society’s 
international nature. Our services, member¬ 
ship, and reputation must continue to grow. 

(3) Today’s students are tomorrow’s com¬ 
puter professionals. I want to use my daily ex¬ 
perience with students to support youth and es¬ 
tablish programs for early identification of our 
future members and leaders. 

(4) Expansion and innovation of services 
cannot depend solely on increased member¬ 
ship fees. We must find other means. I propose 
investigating alternative sources of funding 
(endowments, grants, bequests, sponsorships, 
etc.). Successful innovation coupled with fis¬ 
cal prudence will enable Computer Society 
members to continue as leaders of their 
profession. 

Biography. Von Mayrhauser first became in¬ 
volved in the Computer Society through the 
Technical Activities Board, serving for two 
years as TAB secretary and now as treasurer. 
She is also on the Technical Committee on 
Software Engineering’s executive committee 
and serves as cochair of Compusat 89. In the 
past she was membership chair and secretary 
for the Computer Society’s Chicago Chapter 
and was recently a member of the Long Range 
Planning Committee of the Computer Society. 

She is an associate professor and assistant 
chair in the Department of Computer Science 
at the Illinois Institute of Technology, where 
she has been since 1980. She has also worked in 
industry and appeared several times as an ex¬ 
pert witness for the US District Court. 

Von Mayrhauser received a Dipl. Inf. from 
the University of Karlsruhe (1976) and a PhD 
from Duke University (1979). 



Ronald D. Williams 

Position statement. With 
over 100,000 members, 
the Computer Society is 
recognized as the pre¬ 
mier organization for 
computer professionals. 
Remaining at this level 
of prominence demands leadership in publica¬ 
tions, conferences, and other technical activi¬ 
ties. A broad spectrum of computer profession¬ 
als should be involved through membership 
and volunteer participation to provide this 
leadership. We must therefore commit to mem¬ 
ber services, information, and new-member 
recruiting. 

We should review our periodicals to deter¬ 
mine whether the existing mix of transactions 
and magazines serves our membership well. 
More periodicals may be necessary, or we may 
wish to refocus current periodicals. The Com¬ 
puter Society Press should be considering new 
products. Conference organizers should con¬ 
sider increased use of alternative formats such 
as poster sessions to improve the level of infor¬ 
mation interchange. We should carefully 
monitor our leadership of important standards 
activities. In summary, the Computer Society 
should consider alternatives to the traditional 
and thus be ready to lead rather than just adapt 
to changes. 

Biography. Williams serves on the Computer 
Society Press Board and the Computer Society 
Membership Development Committee, which 
he chaired in 1988. He is also the Division VIII 
representative on the IEEE Membership De¬ 
velopment Committee. In 1987 he served as 
finance chair for the Computer Society Confer¬ 
ences and Tutorials Board. He has been treas¬ 
urer of the Design Automation Technical 
Committee since 1987. He has served as pro¬ 
gram chair for the First and Second Annual 
VHDL Workshops and was registration chair 
for the Ninth International Symposium on 
Computer Hardware Description Languages. 

Williams is on the electrical engineering 
faculty at the University of Virginia. He is also 
a principal faculty member in the Center for 
Semicustom Integrated Systems. His research 
and teaching focus on application-specific 
computer design with primary applications in 
digital signal processing and digital control. 

He received BS and MS degrees in electrical 
engineering from the University of Virginia, 
and a PhD from the Massachusetts Institute of 
Technology in 1984. He is a senior member of 
the IEEE and a member of Sigma Xi, Tau Beta 
Pi, Eta Kappa Nu, and Omicron Delta Kappa. 

He has received Eta Kappa Nu and Electrical 
Engineering Department teaching awards. 



Marshall C. Yovits 

Position statement. I 
firmly believe it is im¬ 
portant for the Computer 
§ociety to be the profes¬ 
sional society represent¬ 
ing computer science 
and computer engineer¬ 
ing. I have been a member of the ACM Council 
and the Computing Research Board, and my 
experience and contacts in this regard are sig¬ 
nificant in establishing Computer Society 
dominance in the profession. 

As a member of the Board of Governors, my 
primary focus has been on you, the members. I 
am chair of the Awards Committee, which has 
been a major factor in recognizing volunteers 
(there are many) who provide service to the so¬ 
ciety. Through our external awards program, 
the society distinguishes itself as a leader in the 
profession. 

I am vitally interested in education and am a 
Computer Society representative to the board 
of the Institute for Certification of Computer 
Professionals. Education is a most important 
responsibility. It represents our future and 
must be emphasized. 

Biography. Yovits, currently on the Board of 
Governors, is chair of the Computer Society’s 
Awards Committee and a representative to the 
board of the Institute for Certification of Com¬ 
puter Professionals. He has played a major role 
on the Educational Activities Board and on the 
Committee on Public Policy. 

Previously he served on the ACM Council 
and was a member of the ACM Education 
Board. For many years he was a member of the 
Computing Research Board and was its first 
chair. He chaired the first Computer Science 
Conference, now a major ACM conference. 
Yovits is the editor of Advances in Computers, 
a hardcover series published by Academic 

A professor of computer science, Yovits was 
dean of science at Purdue University. Previ¬ 
ously he organized and chaired the Department 
of Computer Science at Ohio State University, 
where he was also a professor of electrical en¬ 
gineering. He has held positions with the Of¬ 
fice of Naval Research and with Johns 
Hopkins. 

Yovits received a BS from Union College, 
Schenectady, New York, and a PhD from Yale 
University, both in physics. He is a fellow of 
the IEEE and of the American Association for 
the Advancement of Science. He has held 
elected positions in the AAAS and EduCom. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, MOCO, Inc., PO Box A, 91 Surfside Rd., Scituate, MA 02055; Compmail+, r.eckhouse 

Compilers and accessories for C 


This month we focus on the C lan¬ 
guage. Our coverage includes both com¬ 
pilers and support accessories. The re¬ 
views were written by Dan McAuliffe, 
Richard Tenney, Terry Traub, and 
myself. — R. Eckhouse 

C for everyone 

As an avid fan of QuickBasic and a 
convert to QuickC, I was immediately 
interested when Microsoft offered ver¬ 
sion 2.0 of QuickC for review. I’ve used 
a lot of different C compilers and read 
lots of C books, but I still consider C to 
be a mixed blessing. After all, C is pow¬ 
erful and fast, allowing me to do nearly 
anything I want, but it’s equally capable 
of allowing me to hang myself. Would 
the latest version of QuickC make me 
feel more comfortable with the lan¬ 
guage? The answer is a resounding yes. 

Two things really set Microsoft’s 
QuickC apart from all the competition — 
ease of use and sophisticated program 
development. These two features 
extensively intertwine within QuickC so 
that by describing the one you cannot 
help but describe the other. For example, 
ease of use relates to the human inter¬ 
face, which can mean the excellent menu 
or hypertext help systems. Clearly, hav¬ 
ing a menu system combined with an on¬ 
line help facility means that you can 
write and debug programs more quickly. 

These two goals, ease of use and so¬ 
phisticated program development, re¬ 
sulted from Microsoft’s survey of its us¬ 
ers. It found that, while 72 percent have 
more than five years of programming 
experience, 49 percent said their primary 
reason for purchasing QuickC was to 
learn the C language. Since the most im¬ 
portant factor in purchasing a Microsoft 
product was “value for the money,” the 
aggressive pricing of QuickC at $99 
should guarantee its acceptance by most 


What’s new in version 2.0. I’d like to 
be more specific about ease of use and 
program development. In the case of 
Quick C, this translates into several im¬ 
portant additions to its initial release. 
First, you won’t find a typical user’s 
manual. In its place you get the book 


Let’s C Now and the QuickC advisor. 
Let’s C Now provides an excellent intro¬ 
duction to C and what makes it different 
from other languages. It is written not as 
a tutorial but rather as a factual book for 
the experienced programmer who wants 
to make the transition from, say, Pascal 
to C. It contains plenty of examples, also 
found in the QuickC advisor. Advanced 
topics related to pointers, graphics, fonts, 
and in-line assembly go further to help 
the new user learn how to get the maxi¬ 
mum benefit from the C language. 

Note the mention of in-line assembly 
language code. A new feature of version 
2.0, this offers you the ability to call on 
assembly language when it would other¬ 
wise be difficult or inconvenient to do 
the same thing in C. More likely, though, 
a programmer would use in-line code to 
increase program speed or decrease pro¬ 
gram size. Any way you look at it, it’s a 
nice addition. 

Going back to the original topic of 
ease of use, the QuickC advisor is really 
top-notch. With it you can call up an ex¬ 
planation of language constructs and fea¬ 
tures, find example code that you can cut 
and paste into your program, and obtain 
more detailed explanations for error mes¬ 
sages, all in a context-sensitive manner. 
The only thing not covered are the addi¬ 
tional tools that come with C, such as 
Make and Librarian, and using the com¬ 
mand-line compiler. For these you must 
refer to the Microsoft QuickC Toolkit 
Manual. 

Second, when it comes to program de¬ 
velopment, this latest version of QuickC 
once again shines. QuickC 2.0 now fea¬ 
tures incremental compilation and link¬ 
ing so that minor changes to the program 
under development can be recompiled 
and relinked two to three times faster 
than before. Add to that new features in 
the integrated source-level debugger, and 
you will find that you can solve difficult 
programming problems in much less 
time. More importantly, using the multi- 
windowed debugger a novice program¬ 
mer can step through a program and see 
what each line of code does. 

The seven windows display locals, the 
debug history, help, CPU registers, a 
notepad, and the output and error 
screens. Using these debugging features 
you can change the values assigned to 


variables or be told when they become 
true (that is, they become non-zero) and 
cause your program to stop when it 
reaches a breakpoint. A history feature 
allows you to edit and debug, edit again, 
and then continue to run your program 
from the point where you made the 
change. 

Another new feature is support for all 
memory models (small, medium, com¬ 
pact, large, and huge) as well as the 
NEAR, FAR, and HUGE keywords. 
Compatibly with Microsoft’s C compiler, 
now version 5.1, remains, and a newly 
expanded set of graphic functions lets 
you design charts, fonts, and various 
types of professional graphics programs. 

Summing up. I haven’t gone into the 
details of the QuickC environment since 
most users are already familiar with it. 
Essentially, it offers nine pull-down 
menus labeled File, Edit, View, Search, 
Make, Run, Debug, Utility, and Options, 
each with a number of choices. In addi¬ 
tion, the menus have two settings, full or 
easy, with easy representing the most 
common subset of the full menu. You 
also get a help button and a help key. 

You can select menus by pressing the Alt 
key and then the first letter for the menu, 
or by using a mouse. 

The standard Microsoft editor is easy 
to use and very intuitive. If you prefer, 
you can substitute your own editor, or 
you can redefine the keystrokes for the 
Microsoft editor. Another interesting fea¬ 
ture I have yet to explore is customizing 
the basic menu set. 

I’ve run a number of programs through 
version 2.0 of QuickC, and each worked 
as expected. The debug features have 
proven invaluable for each of the con¬ 
cepts that I wanted to explore further. All 
things considered, I find QuickC to be an 
outstanding product that anticipates my 
needs and meets them in a way that 
makes it fun to program in C. I heartily 
recommend that you purchase or upgrade 
to the latest version of QuickC. 

Contact Microsoft at 16011 NE 36th 
Way, Box 97017, Redmond, WA 98073- 
9717, phone (206) 882-8088. 

— R. Eckhouse 
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A dual-mode version of 
Microsoft C 


It seems fitting to include a quick re¬ 
view of the latest release of Microsoft C 
(MSC). What distinguishes version 5.1 
from previous releases is its support for 
the OS/2 protected mode as well as the 
MS-DOS real mode environments. Other 
enhancements include new command¬ 
line options, changes and additions to the 
C runtime library (including OS/2-spe- 
cific libraries), a bind utility to permit a 
program to run in both OS/2 and MS- 
DOS modes, an incremental linker (such 
as in QuickC version 2.0), some new 
pragmas, changes to the CodeView de¬ 
bugger, and the new Microsoft editor. 
Let’s consider each of these in turn. 

OS/2 support in Microsoft C is proba¬ 
bly the most important feature that would 
cause a user to upgrade from an earlier 
version. One important difference in 
OS/2 versus MS-DOS is the means of 
making operating system cabs. Another 
is in building shareable libraries. Then 
there is the ability to generate OS/2 
threads. Finally, there is the difference 
between the executable file headers for 
OS/2 and MS-DOS. All of these features 
are at least briefly mentioned in the up¬ 
dates to the version 5.0 manual set that 
explains the basis for this release. 

Of course, the user must not forget 
that the reason for programming in C is 
to avoid operating system dependencies 
as much as possible. To that extent the 
manual set only presents the information 
you need and does not attempt to provide 
all the details of OS/2 and the new sys¬ 
tem calls. What you get is an optimizing 
C compiler that generates code for either 
OS/2 or MS-DOS. Using the Bind utility, 
you can generate a program which will, 
after compiling and linking, run in both 
OS/2 protected mode as well as DOS 3.x 
real mode. To do this you can either 
specify a new command-line option or 
call the Bind utility directly. Equally 
easy is selecting the specific library 
(with a command-line option) when link¬ 
ing for one of the operating system envi¬ 
ronments. 

The changes to the CodeView debug¬ 
ger allow debugging of large OS/2 appli¬ 
cations (up to one gigabyte in size), de¬ 
bugging for multiple threads and dy¬ 
namic link libraries, and the ability to 
watch a C or MASM structure, Pascal 
record, or Basic user-defined type. The 
debugger displays, labels, and dynami¬ 
cally updates each element of the struc¬ 
ture and allows you to easily trace 
through a linked list. 

The company claims the incremental 
linker, called ILink, speeds up linking by 


as much as 20 times. This is accom¬ 
plished by a new segmented-executable- 
file format that relinks only those mod¬ 
ules that have changed. Unfortunately, 
ILink only works with OS/2 and Win¬ 
dows applications, so vanilla MS-DOS 
users will find QuickC a better bet to 
take advantage of this feature. 

Version 5.1 of MSC has nine new 
pragmas. One of interest to me was the 
comment pragma that allows you to 
place a comment record in an object or 
executable file. When combined with the 
date and time macros, it means you can 
include this information for reference 
purposes when you want to keep track of 
multiple versions of the same executable 
file. Another pragma, page, when com¬ 
bined with title and subtitle pragmas al¬ 
lows you to format the generated output 
more neatly. 

Last, let me mention the Microsoft 
editor (ME). Frankly, I wasn’t all that 
impressed with it. But that’s because I 
really didn’t want to learn yet another 
editor unless it offers something really 
different. Thus, while the ME allows you. 
to run programs from within it, reports 
compilation errors directly to the source, 
includes macro and regular expression 
support, and lets you modify it, this 
wasn’t enough for me to consider a 
change. On the other hand, a new pro¬ 
grammer who hasn’t made a commitment 
should seriously consider this editor as a 
viable and efficient means for writing 
programs in C or any other programming 
language. 

One thing I really appreciate in ver¬ 
sion 5.1 is the improved installation pro¬ 
cedure. It’s much easier and cleaner, 
with lots of help in making choices in 
terms of what combined libraries to 
build, where to put them, what optional 
libraries to include, and so on. Given that 
there are 14 floppies in the distribution 
kit, automation of the installation is a 
must. By the way, QuickC version 1.0 
was included with the compiler. 

Getting down to system requirements, 
they depend on the operating environ¬ 
ment. In the case of MS-DOS it is 448 
Kbytes, a floppy and a hard disk drive, 
and MS-DOS version 2.1 or higher. For 
OS/2 it is 2 Mbytes, a 5 'A- or 3‘/2-inch 
floppy and a hard disk drive, and OS/2 
version 1.0 or higher. The retail price is 
$450. 

In summary, Microsoft C version 5.1 
continues as a maturing product that 
serves as a standard bearer to which 
other compilers are ultimately compared. 
It is an excellent compiler and one that I 
use in contrast to the many others that I 
could choose from. — R. Eckhouse 
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A not-so-hot TSR and 
C++ compiler 

This review concerns two products 
from Zortech Limited: Hotkey and C++. 

I have found both of them to have seri¬ 
ous bugs and, after months of trying, I 
have yet to have any of the bugs fixed. 

What bugs? Let’s look first at the 
Hotkey Terminate and Stay Resident C 
Library. This $69.95 set of routines en¬ 
ables you to write TSR programs in 
Borland’s Turbo C or Microsoft QuickC. 

I worked with the QuickC version, since 
that’s the compiler I have. 

Hotkey includes a sample program, 
both in source and precompiled for im¬ 
mediate USe. It is a calculator that, once 
loaded, can be accessed at any time by a 
hot key. When I tried to load the pro¬ 
gram, it complained “R6009 — not 
enough space for environment,” even 
though there was certainly sufficient 
space for the environment. After that, my 
computer tended to dump the screen to 
the printer at unpredictable times and 
otherwise behave randomly, so I had to 
reboot it before I could safely use it 
again. When I recompiled the program, it 
behaved the same way. 

I called Zortech for technical assis¬ 
tance. The person I talked to told me that 
I did not have the most recent version of 
the software, so he would send me an 
update that same day. That update (and a 
subsequent one) never arrived, and, if it 
weren’t for a concerned employee who 
actually brought the two diskettes to me, 

I would not have pressed on. What serv¬ 
ice! How disappointing that the diskettes 
didn’t solve the problem. How disturbing 
to discover that they were identical to the 
diskettes I already had. 

Out of desperation (and because of a 
lack of technical support from the com¬ 
pany), I finally tackled the problem my¬ 
self, and I think I solved it. Certain vari¬ 
ables are not properly initialized before 
the size of the environment area is calcu¬ 
lated; as a result, the wrong size is de¬ 
rived. I can now recompile and load the 
calculator. By the way, even though I 
have received a new version of the soft¬ 
ware, it still does not solve the problem. 
From the dates associated with the files, 
it appears that the calculator example 
was never recompiled with the updated 
toolkit routines. 

However, my original goal in all this 
was to convert a utility I had written to a 
TSR program. In this I have not yet suc¬ 
ceeded, even with my correction. Though 
I may be doing something wrong (the 32- 
page manual is quite skimpy), I suspect 
other problems in the Zortech software, 
having to do with opening, reading, and 
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writing files from within a TSR program, 
but life is too short to continue to look 
for them. 

Now consider the situation with 
Zortech’s $149.95 C++ compiler. C++ is, 
in the main, an enhancement of C, with 
features that make it possible to use ob¬ 
ject-oriented programming techniques. 
Object-oriented programming is a “new” 
programming paradigm that is at least 15 
years old. It is based on such famous lan¬ 
guages as Smalltalk and Simula. C++ is 
an especially inviting object-oriented 
environment for practicing programmers 
because it builds on C, which is currently 
a very popular language within both aca¬ 
demia and industry. A C programmer 
need not feel entirely lost when begin¬ 
ning with this new language, though it 
may take some time to adjust to a new 
way of thinking to take full advantage of 
C++. 

I wrote a little menu program to select 
from among several large programs that 
could not fit into memory simultane¬ 
ously. The idea was that the menu pro¬ 
gram would use exec to bring one of the 
large programs into memory, and the 
large program would end by using exec 
to bring the menu back. In this way I 
could use these programs as though they 
were a single program, even though they 
could not all fit into memory at once. 

Old Fortran programmers will recognize 
this technique as chaining. 

The exec routine is supposed to over¬ 
lay the current program with a new pro¬ 
gram. I found that each time my program 
called exec, approximately 1 Kbyte of 
memory disappeared. A few dozen 
rounds of this and the large programs 
would no longer fit into memory, render¬ 
ing the menu useless. I checked and 
found that the Microsoft version of exec 
does not appear to exhibit this problem. 
Zortech told me that a note in the source 
code for exec indicates that this is a 
known error, to be fixed in the next re¬ 
lease, but I looked through the distrib¬ 
uted version of the source code (avail¬ 
able for an extra charge) and I did not 
see it. Even if it were there, that’s hardly 
a solution. 

The next thing I tried with C++ was to 
compile the shapes example from Bjarne 
Stroustrup’s book The C+ + Program¬ 
ming Language. The definition of a gslist 
on page 217 comprises the following 
four lines: 

typedef shape* sp; 

declare(gslist,sp); 

typedef gslist(sp) shape_lst; 

typedef gslist_iterator(sp) sMterator; 

The second line causes Zortech’s C++ 

compiler to emit 


Syntax error: cannot uniquely deter¬ 
mine which function ‘slist’ to call 

In the three months since I reported 
this, I have received no reply as to what 
the problem could be. In addition, the 
Zortech package presents other small an¬ 
noyances. Programming examples in the 
manual were not taken from sources that 
were actually compiled and run, so I 
found a variable declared “chat” instead 
of “char” and a function definition that 
includes an illegal semicolon immedi¬ 
ately after the formal parameter list. The 
include files do not contain prototypes 
for all library functions. So, for example, 
the sample menu program included with 
the C++ compiler does not complain 
when the bdos function is called with 
two instead of three arguments. 

The package includes a version of 
Make, the program maintenance pro¬ 
gram, which Zortech calls zmake. It 
seems to work fine, as far as it goes, but 
it is incapable of allowing commands to 
redirect output. 

A graphics library is included as well. 
It uses the typical mathematical orienta¬ 
tion of having the coordinates (0,0) in 
the lower-left corner with the y coordi¬ 
nate increasing upwards and the x coor¬ 
dinate increasing to the right. Unfortu¬ 
nately, most programmers will be used to 
finding (0,0) at the upper-left corner with 
the y coordinate increasing downwards. 

In addition, the library includes a dis¬ 
play package to make writing window- 
based user interfaces easier. The docu¬ 
mentation is a bit skimpy, relying on the 
general knowledge of the reader rather 
than explaining much about, say, the 
video attribute. What the manual does 
say about the video attribute applies to 
monochrome displays, but the package 
will support the usual attributes for color 
displays if you can figure out the correct 
parameters to use. 

So what good news is there? Well, for 
the calculator problem in section 3.1 of 
Stroustrup’s book, I compared the per¬ 
formance of Advantage (Glockenspiel) 
C++ coupled with the Microsoft C 5.0 
compiler to that of the Zortech C++ com¬ 
piler. Zortech compiled much more 
quickly, produced no warnings about 
variable names exceeding 31 characters, 
and produced a smaller executable file. It 
was wonderful. It makes me wish I could 
trust the product for other projects. 

Zortech is located at 1165 Massachu¬ 
setts Ave., Arlington, MA 02174, phone 
(617) 646-6703 or (800) 848-8408. 

— R. Tenney 


Hotkey: Reader Service 23 
C++: Reader Service 24 


An incremental C 
compiler 


One of the more time consuming, and 
consequently annoying, features of soft¬ 
ware development is the edit, compile, 
link, and debug cycle. If you have a large 
source file and frequently make small 
changes, you can spend a good deal of 
your time waiting around for the system 
to compile and link before testing your 
changes. Rational Systems’ Instant-C/ 
16M system offers a significant improve¬ 
ment to this process, and you don’t have 
to give up your favorite compiler to use 

Instant-C/16M is an incremental com¬ 
piler in that it only recompiles the 
changed portions of your program. As 
soon as the program is recompiled it is 
ready to run, without any intermediate 
linking. Instant-C/16M provides a full 
interactive development environment 
similar to many C interpreters, including 
a full-screen editor, a compiler, a func¬ 
tion library, and an excellent source- 
level debugger. 

Instant-C/16M runs in the protected 
mode of the 80286 or 80386 processor 
and can address up to 16 Mbytes of 
memory. It achieves this result by using 
Rational Systems’ DOS/16M product, 
sometimes referred to as a DOS exten¬ 
der. DOS sees any DOS/16M application 
as a 24-Kbyte program, while the appli¬ 
cation itself sees a standard DOS that 
supports a full 16 Mbytes of memory. 
Thus, Instant-C/16M can handle very 
large programs, as long as you have suf¬ 
ficient physical memory. 

One of the major advantages to this 
approach, and probably the major appeal 
of Instant-C/16M, is the ability to debug 
very large programs. If you are using 
Microsoft Codeview, for instance, the 
size of the programs you can debug is 
severely limited by DOS and the fact that 
Codeview itself is so large. 

All you need do to run Instant-C/16M 
is copy the file ic.exe into a directory in 
your system path. The majority of the 
other files supplied with Instant-C/16M 
are for building tailored copies of the 
system. 

Two utility programs supplied with 
Instant-C/16M help you configure the 
screen and keyboard layouts. Both pro¬ 
grams are cryptic and clumsy to use. For 
example, if you want to change the color 
scheme for the display, you must know 
the numeric value of the DOS display at¬ 
tribute code. 

You can change a number of Instant- 
C/16M system options from within the 
interactive environment by simply as¬ 
signing values to the system variables as 
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if they were global entities in one of your 
programs. These options control the way 
the editor formats program text, the type 
checking performed in assignment state¬ 
ments, the implementation of return ar¬ 
gument type checking, and a number of 
other features. 

The Instant-C/16M editor comes in 
two flavors: a stand-alone version and a 
version integrated into the interactive 
environment. The different versions pro¬ 
vide nearly identical functionality. The 
editor is adequate, but provides little in 
the way of competition for other com¬ 
mercial editors directed specifically at 
the programming community. It has a 
number of deficiencies, including the 
failure to highlight regions of text 
blocked off for copying or moving, and it 
doesn’t have an Undo feature, something 
often difficult to get along without. 

Instant-C/16M includes a pretty 
printer as part of the editor. It is invoked 
automatically as part of the editing proc¬ 
ess. I personally found it very annoying, 
especially when loading files created 
from another editor. I was unable to con¬ 
figure the editor to make the pretty 
printer format the text the way I wanted 
it to look. 

Once you’ve made all of the necessary 
changes to your text file, you can exit the 
editor with the Ctrl-F command. Instant- 
C/16M recompiles the function, leaves 
the editor if it finds no errors, and dis¬ 
plays the Instant-C command prompt or 
the DOS prompt if you are operating in 
stand-alone mode. If errors show up dur¬ 
ing the compilation, you remain in the 
editor, with the cursor positioned near 
the source of the error and the appropri¬ 
ate error message displayed. 

The ic.exe module contains a large set 
of the Instant-C/16M standard function 
library. Other portions of the library, 
such as the math functions, are included 
in separate files. You can create a new 
version of the Instant-C/16M executable 
module by adding, deleting, or changing 
functions in the standard library. You 
can also replace the entire library with 
either the standard Microsoft or Lattice 
function library. You can also add com¬ 
mercially available libraries to the 
system. 

I used the detailed instructions sup¬ 
plied with Instant-C/16M to create a new 
version of Instant-C/16M that included 
the Microsoft C, Version 5.1 library in¬ 
stead of the standard Instant-C/16M li¬ 
brary. The test programs I ran with the 
resulting version of Instant-C/16M 
worked without any problems. However, 
I cannot report comparable success when 
trying to use Instant-C/16M with two 
commonly used commercial packages. In 
the first case, I tried to load a program 
that used the Greenleaf Communications 


Library and received an error message 
telling me that a macro in one of the 
Greenleaf Include files redefined an ex¬ 
isting Exit function, which was indeed 
the case. If the macro definition was 
commented out, the library loaded suc¬ 
cessfully. But this solution was unaccept¬ 
able, since the macro was clearly in¬ 
tended to replace the existing function, 
and the program could not function prop¬ 
erly without the replacement. 

I encountered more critical problems 
when trying to load the C-scape Interface 
Management System libraries from 
Oakland Group. After trying several ap¬ 
proaches and receiving a stream of error 
messages, I called Rational Systems, but 
was unable to find anyone who was fa¬ 
miliar with the C-scape library. At that 
point I abandoned the idea, feeling the 
effort required was not worth the poten¬ 
tial gain. 

The documentation package for In- 
stant-C/16M is excellent. It consists of 
approximately 500 pages bound in a 
three-ring binder. Separate tutorials 
cover the basic system and the editor. 

The system commands are listed 
alphabetically, as are the library func¬ 
tions. Examples are included along with 
each. 

Instant-C/16M is not an optimizing 
compiler, so you will probably want to 
continue to use the compiler of your 
choice. This may present a serious cost 
consideration for many users. Instant-C/ 
16M retails for $795 for a single copy. 
This price, together with the cost of your 
optimizing compiler, can result in a total 
cost rivaling the purchase price of a PC 
itself. 

In summary, I found Instant-C/16M to 
have some very strong points. It can sub¬ 
stantially improve software development 
time and permits easy debugging of very 
large programs. However, the difficulty 
in using many commercially available li¬ 
braries can severely limit its usefulness. 
For this reason, I am reluctant to give a 
strong recommendation to the product. 

You can contact Rational Systems 
through PO Box 480, Natick, MA 
01760, phone (617) 653-6006. 

— D. McAuliffe 
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Powerful menuing 
software 

What do a “bob,” “sed,” “slug,” and 
“ted” have to do with computing? They 
are the key elements in C-scape, an ob¬ 
ject-oriented screen management system 
from the Oakland Group. If you are 
interested in adding menus and windows 


to your software, then this is the system 
to consider. The new version 3.0 is an 
significant improvement over version 2.0 
with lots of new features, including the 
simultaneous mixture of text and graph¬ 
ics on the same screen. 

But let’s drop back a bit. In our last 
review of C-scape ( Computer , Feb. 1988, 
pp. 89-90), we said “What really sets C- 
scape apart from the other systems is that 
it is a complete collection of C functions 
for managing screens.” In that sense it 
could be called a programmer’s toolbox. 
But included with C-scape is Look & 
Feel, an applications generator that pro¬ 
duces C code without requiring you to 
immediately learn all the details of C- 
scape. This makes the product more 
powerful because it becomes extremely 
simple to build complex data-entry 
screens with minimum effort. 

What is C-scape? While you write C 
functions to manipulate objects, it is the 
objects that are important. A set of func¬ 
tions let you create, observe or modify 
the contents of, or destroy an object, but 
each different data object contains and 
controls a set of components. 

The most important C-scape data ob¬ 
jects are the menu, field, and sed objects. 
The menu object controls the structure 
and format of the screen. It acts as a tem¬ 
plate, letting normal text be displayed on 
the screen along with special data-entry 
areas called fields. Fields consist bf two 
different type of positions: writable and 
nonwri table. 

The sed (screen editor) object takes 
one of these menu templates and gives it 
its personality. A sed acts as a frame 
through which you can see and manipu¬ 
late the menu object; the sed does the 
work of putting the menu on the display 
and getting information from it. More 
than one sed can appear on the screen at 
any time, and you can modify the posi¬ 
tion and size of a sed. In cases where the 
dimensions of the sed are smaller than 
those of the menu, the sed will automati¬ 
cally scroll. Most of the data contained 
in a sed object consists of information 
such as its current location on the dis¬ 
play, its colors, the current field number, 
and the current position in the field — 
information that has to do with display¬ 
ing a screen. 

Screens can include various menuing 
systems, borders, windows, scrolling 
lists, and note pads. The windows can be 
tiled, overlaid, and exploding. There is 
automatic vertical and horizontal scroll¬ 
ing for screens, and windows can be 
larger or smaller than the display. Menus 
can be pull-down and nested, supporting 
highlighted scroll bars and first-character 
selection. Mouse support allows you to 
move or resize windows or select items 
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from menus. 

Fields can be of unlimited length. 

They can be masked, protected, marked, 
required, and named. There is numeric 
and text data validation. Also included is 
an extensive system for producing con¬ 
text-sensitive help within programs. 

The bob, or basic object, is new in ver¬ 
sion 3. It is a frame for an object that al¬ 
lows the object to fit into a sed. For ex¬ 
ample, suppose you want to create a 
simple data-entry screen that contains a 
list of numbers. You may want to scroll 
the list of numbers without scrolling the 
rest of the data-entry screen. To do this, 
you need to have a sed within a sed, 
where the inner sed can scroll independ¬ 
ently of the outer sed. The problem is 
that there is no easy way to do this with¬ 
out writing a lot of code. That’s where 
the idea for a bob came from. 

C-scape provides two higher-level 
menuing systems. One, the slug, creates 
nested menus similar to those used in Lo¬ 
tus 1-2-3 or Look & Feel. The other, the 
framer system, creates menus that pull 
down from a menu bar that runs across 
the top of the display. The slug menu 
system can create nested menus that are 
either horizontal or vertical. The user 
moves through a set of menu choices 
with descriptive prompt messages shown 
for each choice. 

The new text editing (or ted) functions 
include word wrap, search and replace, 
and vertical and horizontal block com¬ 
mands. Also new is the Oakland Win¬ 
dowing Library (or OWL). Using OWL, 
applications built with C-scape become 
portable between operating systems be¬ 
cause all the lower-level, machine-de¬ 
pendent routines are isolated in the 
OWL. 

C-scape provides sound function to 
alert the user or to signify a data-entry 
error. The arguments for the function are 
wavelength and duration. Alternatively, a 
simple tone function chooses its own set 
of values. 

A 600-page, indexed user’s manual, 
rather than devoting a section to a tuto¬ 
rial, discusses each object type in turn. It 
includes sample sections of code to illus¬ 
trate the points discussed. The latter half 
of the manual serves as a function refer¬ 
ence guide, and a quick reference card 
summarizes all the C-scape functions. 

Look & Feel. At this time, the 
Oakland Group has only released a Beta 
version of Look & Feel (LNF). Normally 
we don’t consider such releases for re¬ 
view because significant changes can oc¬ 
cur between the Beta and the final re¬ 
lease. But rather than hold this review up 
any longer, we decided to describe the 
changes to LNF since it’s an important 
part of the overall system. Users cur¬ 


rently receive a modified version of LNF 
to run under version 3.0 of C-scape and 
will receive the new version of LNF as 
soon as it is released. 

Look & Feel is an interactive editor 
that generates the C source code and C- 
scape function calls from the screens and 
menus designed interactively. Mouse in¬ 
put will be supported, although it was 
not in the Beta test version, nor was sup¬ 
port for the context-sensitive help 
screens. It should be possible to load 
ASCII files as well as files from Dan 
Bricklin’s Demo program, but we didn’t 
test either feature. 

Menu choices appearing at the top of 
the user’s screen include Disk, Screen, 
Field, Block, Editor, Nesting, Tools, and 
Quit. As of press time, the choices are 
activated by pressing the F10 key. Quick 
keys (such as Ctrl-J for Disk-Load) cut 
down on keystrokes. The name of the 
screen presently being edited appears in 
the lower left of the screen. 

The disk command lets you save, re¬ 
store, and generate C code. The screen 
command lets you set borders, titles, and 
colors, and resize or move a screen. To 
create a sed, you open it and then use the 
screen edit box to modify its parameters. 
The Screen-Go command lets you test a 
newly created or modified screen. 

If you generate source code with LNF, 
you can use it in several ways. For in¬ 
stance, you can 

• Use a text editor to extract the C- 
scape statements and insert them into 
your own code. 

• Compile the code and call the routine 
from your own program. 

• Generate the code using the “Gener¬ 
ate Test Code” option, compile it, 
link it with the C-scape library, and 
run the executable program. 

You use the Field command to create 
fields out of writable and nonwritable 
data; the # is used for writable and any 
other character for nonwritable. The 
Field command allows you to set and 
modify all the parameters of the field 
(such as function, variable type, etc.). In 
certain fields in a dialog box, you can 
view a list of possible choices by hitting 
the + key. 

Block commands are used to move, 
copy, and paste. The set of editor com¬ 
mands includes search and replace. Since 
LNF includes a complete text editor, you 
can edit the generated code as easily as 
the screens and menus. If you want two 
screens to always appear and disappear 
in tandem, you embed them using the 
nesting command. Other nesting com¬ 
mands allow you to attach screens so that 
the attached screen only appears when 
the screen to which it is attached is vis¬ 


ible. The User Functions subcommand 
allows a screen to return a value, while 
the Extract subcommand extracts a 
nested screen from its parent. The Tools 
command includes line drawing and the 
ability to select a character from the ex¬ 
tended ASCII set. 

The preliminary manual for LNF is 
organized more as a tutorial than a refer¬ 
ence guide. It should prove quite valu¬ 
able to the new C-scape user who wants 
to generate screens and menus without 
having to learn all of the details of C- 
scape at the beginning. 

Summing up. Because you can have 
either a program generator (using Look 
& Feel) or a toolbox filled to capacity 
with every conceivable screen function, 
C-scape gives you a choice in program¬ 
ming style. The novice can begin with 
Look & Feel and migrate to the full sys¬ 
tem when the need to customize for a 
particular application occurs. The expert 
can use Look & Feel to save space by 
substituting binary files for runtime code 
callable by the C-scape interface man¬ 
agement system. 

We tested the system by compiling 
embedded C-scape routines using both 
the Microsoft C and QuickC compilers. 
Between the manual and the error mes¬ 
sages generated, we were able to make 
all of our programs work successfully. 
We had to rewrite older code, developed 
under version 2.0, because of differences 
between versions. A chapter in the user’s 
manual describing these differences pro¬ 
vided much assistance. 

Technical support includes a toll-free 
number and a 24-hour bulletin board. 

The company offers a 30-day review pe¬ 
riod and requires no royalties or runtime 
licenses if you embed C-scape functions 
in your code. C-scape with Look & Feel 
costs $399, including source code. This 
is an excellent price for a versatile prod¬ 
uct that ranks number one in screen man¬ 
agement systems. Oakland Group, 675 
Massachusetts Ave., Cambridge, MA 
02139, phone (617) 491 -7311 or (800) 
233-3733. — R. Eckhouse with 
D. McAuliffe 

Reader Service 26 


“C”erious Toolkit Plus 

“C”erious Toolkit Plus from TSR Sys¬ 
tems is a C programming library for the 
PC that provides support for disk I/O, 
video routines, and terminate-and-stay- 
resident programming. It is compatible 
with Watcom C 6.5, Microsoft C 5.x, and 
Borland Turbo C. I reviewed the version 
for Turbo C. 

Experienced C programmers will rec- 
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UIST ’89 

Second Annual Symposium on User Interface Software and Technology 
Williamsburg, Virginia, November 13-15,1989 


Like the first UIST symposium, held in Banff, Alberta in October 1988, 
this symposium is designed to bring together researchers and practitioners 
in the rapidly growing field of user interface software and technology. The 
program is a mix of invited plenary presentations, contributed technical 
papers and both formal and informal panel sessions. One of the major goals 
is to foster interactions among attendees, accordingly, room will be 
provided for informal gatherings and birds-of-a-feather sessions. In addi¬ 
tion, there will be a get acquainted reception the evening of Sunday 
November 12 to get the symposium off to a spirited start. 

UIST ’89 Program 

Plenary speakers 

Jim Thomas, Battelle Pacific Northwest Laboratories 
Jaron Lanier, VPL research 

Technical papers 
Automatic Layout 

William Bennett Stephen J. Boies John D. Gould Sharon L. Greene Charles 
F. Wiecha IBM T. J. Watson Research Center 'Transformations on a Dialog 
Tree: Rule-Based Mapping of Content to Style" 

Steven Feiner Clifford M. Beshers Department of Computer Science, 
Columbia University "Automated Generation of Graphical Interfaces" 
Gurminder Singh Mark Green Department of Computer Science, Univer¬ 
sity of Alberta "A System for Creating Highly Interactive Screen Layouts" 
3D/Gesture 

Steven Feiner Doree Duncan Seligmann Department of Computer Science, 
Columbia University "Specifying Composite Illustrations with Com¬ 
municative Goals" 

George Robertson Stuart K. Card Jock D. Mackinlay Xerox Palo Alto 
Research Center 'The Cognitive Coprocessor Architecture for Interactive 
User Interfaces" 

David Sturm an David Zelter Steve Pieper Computer Graphics & Animation 
Massachusetts Institute of Technology "Hands-on Interaction with Virtual 
Environments" 

Graphical Techniques and Constraints 

Brad Meyers Brad Vander Zanden Roger B. Dannenberg School of Com¬ 
puter Science, Carnegie Mellon University "Creating Graphical Interac¬ 
tive Application Objects by Demonstration" 

Scott Hudson Department of Computer Science, University of Arizona 
"Graphical Specification of Flexible User Interface Displays" 

Qujing Mao Juwei Tai Institute of Automation, Chinese Academy of 
Sciences “Defining the Presentation of Application Data by a Graphical 
Language" 

User Interface Structures I 

Anjo Anjewierden Jan Wielemaker Department of Social Science Infor¬ 
matics, Universiteit van Amsterdam "Separating User-Interface and 
Functionality Using a Frame-Based Data Model" 

Pedro Szekely USC/Information Sciences Institute "Standardizing the 
Interface Between Applications and UIMS’s" 

Jonas Lowgren Department of Computer and Information Science, Linkop- 
ing University "An Architecture for Expert System User Interface" 

User Interface Structures II 

Roger Dannenberg Dale Amon School of Computer Science, Carnegie 
Mellon University "A Gesture-Based User Interface Prototyping System" 
Niels Carlsen Niels Jorgen Christensen Hugh A. Tucker Graphical Comm. 
Department, Technical University of Denmark "An Extended Event Model 
for Building User Interface Frameworks" 

Scott McKay Michael McMahon Symbolics, Inc. and William York Inter¬ 
national Lisp Associates "A Presentation Manager Based on Application 
Semantics" 

Tool Kits 

Scott Meyers Steven P. Reiss Carolyn Duby Department of Computer 
Science, Brown University "Using GELO to Visualize Software Systems" 
John Vlissides Mark A. Linton Center for Integrated Systems, Stanford 
University "Unidraw: A Framework for Bull ding Domain-Specific Graphi¬ 
cal Editors" 

Michael K. Powers Xerox Corporation "Ensemble: A Graphical User 
Interface Development System for the Design and Use of Interactive 
Toolkits" 


A Larger View of User Interface Design 

Deborah Hix Computer Science Department, Virginia Polytechnic In¬ 
stitute* State University "A Procedure for Evaluating Human-Computer 
Interface Development Tools" 

Michael Coble Elizabeth G. Hetzler Steven W. Totten McDonnell Douglas 
"Improving Usability by Sharing Knowledge" 

If you have further questions contact: 

John Sibert, UIST ’89, Department of EE and CS, The George Washington 
University, 801 22nd Street NW, Washington DC 20052 

Travel and Accommodation: 

Williamsburg Virginia is located in the Tidewater region of the Mid-Atlan¬ 
tic seaboard. It is served by three nearby airports Norfolk International (45 
minutes away), Richmond-Byrd (40 minutes), and Newport News-Patrick 
Henry (20 minutes). All have available public transportation to Wil¬ 
liamsburg. There is direct Amtrak service from Boston, New York, 
Philadelphia, Baltimore, and Washington D.C. 

Headquarters for the Symposium is the Fort Magruder Inn and Conference 
Center. We have reserved a block of rooms at the rate of $74 for single and 
$82 for double occupancy. Reservations can be made directly with the 
hotel by telephone 1-800-446-4082 (in Virginia 1-800-582-1010). 
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ognize the value of many of the func¬ 
tions provided in this library. Standard C 
compilers such as Microsoft C and 
Borland Turbo C omit support for such 
basic functions as screen cursor control, 
clearing the screen, intercepting key¬ 
board hardware interrupts and stuffing 
the keyboard buffer, and other tasks es¬ 
sential to developing modern software. 
Such tasks are relegated to users of the 
compilers, who typically develop custom 
libraries of assembly language and C 
routines to supplement the default 
libraries. 

In recent years compiler makers have 


Review notes 

Expanded Windows color display. 

hDC Windows Color version 2.1 from 
hDC Computer, 15379 NE 90th Street, 
Redmond, WA 98052, phone (206) 
885-5550, is a utility for Microsoft’s 
Windows (286 or 386) versions 2.0 or 
higher. This video device driver and 
utility enhances and expands the color 
display capabilities of Windows. The 
Windows EGA and VGA video device 
drivers provide only 8 colors. hDC 
Windows Color expands this to 16 
colors. It also allows you to change 
the color palette registers to display 
any 16 of the possible 64 colors. 

Installation was easy. The software 
is not copy protected and comes on a 
5'A-inch 1.2-Mbyte diskette (3'/2-inch 
diskettes are also available), A utility 
(build.exe) copied the color.exe and 
hDClib.exe files from the distribution 
disk to my hard disk. Color.exe is the 
utility that allows you to change the 
color palette registers. hDClib.exe is 
used by color.exe. The two files used 
128.432 bytes of disk space. Build.exe 
uses the same prompt and menu for¬ 
mat that the Windows setup utility 
uses. Once you run build.exe, you 
must run the Windows setup utility to 
install the hDC video device driver. 
The instructions displayed by 
build.exe explain how to save custom¬ 
ized PIF files and the win.ini file. 
Without care, customized PIFs and 
changes to win.ini will be overwritten 
when setup reinstalls Windows. 

The color.exe utility allows you to 
adjust the mix of red, green, and blue 
used to display each color. Changes 
take effect immediately, so you can 
see how they affect the display. 
Changes are permanent, so you need 


begun to add more support for the PC’s 
BIOS and DOS services, making redun¬ 
dant many of the older third-party librar¬ 
ies. Still, there’s room for improvement, 
and TSR Systems attempts to meet the 
needs of modern programmers with 
“C”erious Toolkit Plus. 

Many of the routines in “C”erious 
Toolkit Plus are simple BIOS routines 
that many C programmers have probably 
written before, such as BIOS video and 
disk I/O routines. It’s questionable 
whether you need to purchase a library to 
perform functions so easy to write. On 
the other hand, some windowing and di¬ 


not run the color utility every time. 

The color.exe display is a cross be¬ 
tween a dialog box and a window. It uses 
nonstandard buttons for things that 
should really be on a menu bar. Still, it’s 
obvious what the buttons are for and how 
the window works. The help displays are 
useful, but the mix of nonstandard but¬ 
tons and scroll bars caused me to miss 
some of the help text the first two times I 
displayed it. Also, it’s not obvious how 
to close color.exe, since there’s no close 
button in the window. The help text ex¬ 
plained that you can only close from the 
color icon, but that’s one of the help sec¬ 
tions I originally missed. It looks as if 
the designers felt they could improve 
upon the standard Windows interface, 
and I think they did. However, the depar¬ 
ture from the standard caused me some 
initial confusion. 

There are two “undo” buttons. The 
“standard” button will reset the palette 
registers to their standard values. The 
“reset” button will reset the palette regis¬ 
ters to what they were before color.exe 
was invoked. Both help reduce the anxi¬ 
ety that comes with experimentation, and 
this tool screamed “experiment with 
me.” I hate to admit how much time I 
spent adjusting and readjusting the colors 
on my display. 

Color.exe takes approximately 24 
Kbytes of memory. The exact amount 
will depend on what’s running in other 
windows — it’s a function of Windows, 
not color.exe. The only problem I see is 
due to a Windows design feature. hDC 
Windows Color replaces the standard 
Windows video device driver. If you 
have a video board that has its own non¬ 
standard Windows driver, you must 
choose between it and the hDC driver. 


rect video memory access routines are 
less simple to write, and it’s more sen¬ 
sible to use tested, prewritten routines 
than to reinvent the wheel. 

More powerful than the video routines 
are the terminate-and-stay-resident rou¬ 
tines, which allow programmers to fash¬ 
ion memory-resident programs without 
too much difficulty. While the tech¬ 
niques for doing this are fairly well 
known, it’s still somewhat tricky; having 
the sample code and tested routines is 
convenient. “C”erious Toolkit Plus pro¬ 
vides just enough sample code to enable 
a programmer to produce memory-resi- 


I found that hdc Windows Color pro¬ 
vided an inexpensive ($49.95) way to 
improve my productivity. The increased 
number of colors and the ability to 
change the color palette significantly in¬ 
creased my ability to customize Win¬ 
dows and Windows applications. This let 
me create a more pleasing and hence less 
tiring screen display. —N. Davids 

New 386 PC. PC Genius has just come 
out with a fast (33 MHz) 386 in a tower 
case with a price that’s really special. 

The base machine sells for $3,179 and 
includes a Micronics motherboard with a 
32-Kbyte cache, 1-Mbyte RAM, 1.2- 
Mbyte floppy with combined hard disk 
and floppy controller, and a 101-key 
keyboard. The same machine with a 64- 
Kbyte cache sells for $3,295. Add an I/O 
board ($65), a Paradise VGA display 
adapter ($265), a NEC 3D display 
($725), and a 40-Mbyte Seagate 251-1 
($395) and you have a fully loaded ma¬ 
chine. For $675 you can buy a 33 MHz 
387 coprocessor, or for $1,525 you can 
get the Weitek chip. Finally, you can add 
up to 16 Mbytes on the memory board 
using 1-Mbit chips. 

I compared the evaluation unit to my 
slower 20 MHz PC Genius machine, and 
the results were impressive. The numbers 
were 11,379 Dhrystones, 1,503 charac¬ 
ters per second, and 2,445.8 Whetstones 
for the 33 MHz system and 4,552, 1,786, 
and 1,005.8, respectively, for the 20 
MHz machine without cache. So, you 
can get a 386 machine from two to three 
times faster than last year’s machine for 
nearly the same price. 

Having owned the 20 MHz machine 
for 16 months now, I can attest to the 
quality of both PC Genius and Micron- 
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dent programs without resorting to as¬ 
sembly language. 

The string routines do not provide 
much that the standard C library does not 
already have. For example, a judicious 
use of sprintf() and strchr() will duplicate 
much of the functionality of “C”erious 
Toolkit Plus’s string functions. The disk 
and printer routines are rather disap¬ 
pointing as well; they mostly duplicate 
simple DOS and BIOS calls that any pro¬ 
grammer armed with a decent hardware 
reference can write in a few minutes. 

In its current version, “C”erious 
Toolkit Plus is still a little rough around 


ics. I’ve had one failure, a bad memory 
chip, and it was replaced immediately. 
This new machine in its tower case is 
easy to set up, change cards, and add 
additional drives. 

Documentation is only fair, as is typi¬ 
cal of clone machines. Micronics supplies 
a manual briefly describing the mother¬ 
board and offers both a very complete di¬ 
agnostic system (excellent manual and 
menu-driven software) and a set of util¬ 
ity programs to set up the CMOS con¬ 
figuration RAM, an extended-memory 
manager, etc. The other manuals consist 
of those packed with the display, I/O, 
and disk units. 

I remain very impressed with PC Gen¬ 
ius (101A Tower Office Park, Woburn, 
MA 01801, phone (617) 933-8442) given 
their excellent service and the reliability 
and quality of their machines. As a result 
I continue to rate them highly and recom¬ 
mend them strongly. By the way, PC 
Genius has entered into an agreement 
with PC Exchange for trading in your old 
PC, XT, or AT. You can contact PC Ex¬ 
change at (617) 944-4752. 

— R. Eckhouse 

DBL — A Business Programming 
Language is produced by Digital Infor¬ 
mation Systems, 11070 White Rock Rd., 
Suite 210, Sacramento, CA 95670, phone 
(916) 635-7300. The DBL programming 
language suits business programming 
and data processing activities. It has a 
structured programming format, which 
allows you to express solutions in 
straightforward coding. DBL is, to a 
large extent, portable between operating 
systems (VMS, Unix, and MS-DOS). In 
fact, you need only recompile, relink, 
and then run the programs on the new 


the edges. The manual is a bit terse and 
lacks an index (the index is “to be 
added”). Unfortunately, unlike most such 
reference manuals, this manual is ar¬ 
ranged by topic rather than in alphabeti¬ 
cal order by function name. It’s hard to 
quickly look up a particular function be¬ 
cause you must stop and remember the 
topic. 

Before investing in this package, pro¬ 
grammers looking for a solid, profes¬ 
sional library would be advised to check 
out some of the more mature packages, 
such as Blaise Tools, Windows for C, C- 
Worthy User Interface, Vitamin C, and 


system. The only time you need to 
change a program is when the original 
applications were designed expressly for 
a particular operating system and relied 
on facilities available only on that 
system. 

The main components of DBL are 

• The compiler, which accepts source 
files containing DBL language state¬ 
ments, and creates object files with 
system-level information that de¬ 
scribe the actions the programs 
require. 

• The runtime code, which performs 
the actions requested by DBL pro¬ 
grams during execution. 

• The external subroutine library 
(Dlib), which is a DBL-supplied col¬ 
lection of external subroutines. 

• The multikey indexed sequential ac¬ 
cess method (ISAM), which reuses 
released data space and provides a 
powerful file structure that improves 
random as well as sequential record 
processing. 

• The symbolic debugger, which per¬ 
mits programs to run in a special de¬ 
bugging mode. 

• The assembly language interfacing, 
which allows access to assembly- 
level external subroutines. 

The documentation is well written, and 
easy to read. The price of DBL falls be¬ 
tween $500 and $10,000, depending on 
hardware. I consider it a good business 
programming language, recommended 
especially for developers of applications 
in DP and IS areas. — M. Dediu 

Print Spooler. PrintQ 4.0 from Soft¬ 
ware Directions, 1572 Sussex Turnpike, 
Randolf, NJ 07869, phone (201) 584- 


C-scape. For not much more money, 
some of these packages offer much more 
power than “C”erious Toolkit Plus and 
come with better documentation. Even 
shareware libraries, such as the Unicorn 
library, allow programmers to try before 
they buy. In such a crowded market, I 
doubt there’s room for another entry- 
level product, but with a little improve¬ 
ment “C”erious Toolkit Plus might be 
worth another look. TSR Systems, 1600 
B Main St., Port Jefferson, NY 11777, 
phone (516) 331-6336. — T. Traub 
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8466, is a true print spooler, using 
disk, not memory, space. Once 
loaded, it requires only 60,688 bytes 
of memory. If you have expanded 
memory with an EMS 3.2 (or later) 
driver, it will load itself into ex¬ 
panded memory. In this configuration 
it requires about 10 Kbytes of mem¬ 
ory below 640 Kbytes and about 65 
Kbytes of expanded memory. 

By using a disk file for its buffer, 
PrintQ not only reduces its memory 
requirements, it allows almost unlim¬ 
ited spooling and lets printing con¬ 
tinue after a system hang or power 
fail. Each file sent to the printer is 
maintained as a distinct entity, called 
a print file, within the printer queue 
file. There are about a dozen parame¬ 
ters associated with each print file. 
This gives you an amazing amount of 
control over the printing process. 

The manual is well written, with 
clear illustrations and detailed de¬ 
scriptions of PrintQ’s menus and 
forms. The index could be expanded; 
for instance, there is no entry for 
EMS or expanded memory. However, 
it’s one of the best user manuals that I 
have seen. PrintQ is not copy pro¬ 
tected. The license agreement states 
that you can physically transfer the 
program to another computer system 
as long as PrintQ is used on only one 
system at a time. 

I like this product. It’s the best print 
spooler I have seen, and I recommend 
it without reservation to everyone 
who uses a printer. If they had an 800 
technical support number and at least 
one year of free technical support. I’d 
give PrintQ 4.0 a perfect 10. 

— N. Davids 
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offer power, expandability 


Digital’s new RISC systems 

Digital Equipment markets the new 
DECsystem 5810 and 5820 as its most 
powerful and expandable multiuser 
reduced instruction set computers. The 
systems combine Mips Computer Sys¬ 
tems’ R3000 RISC processor and R3010 
floating-point unit with the XMI-based 
VAX 6000 system platform. 

The company claims an 18.7 integer 
MIPS performance for the single-CPU 
5810 to up to 36 integer MIPS for the 
dual-CPU 5820, with ratings based on 
the Dhrystone benchmark and grep, 
nroff, yacc, and diff Unix utilities. 

The systems feature two levels of 
cached memory, an internal clock speed 
of 25 MHz, optimizing compilers, up to 
five VAXBI channels, 32 Mbytes (5810) 
or 64 Mbytes (5820) of standard error 


checking and correction memory, Ultrix 
software, TCP/IP networking and Net¬ 
work File System support, and a one- 
year warranty. 

Prices for the DECsystem 5810 start 
at $99,500 for the base system and 
$121,500 for the entry system. Prices 
for the DECsystem 5820 start at 
$174,900 for the base system and 
$196,500 for the entry system. Pricing 
includes licensing. 

The new DECsystem 5400 RISC com¬ 
puter also uses the Ultrix operating sys¬ 
tem. It features 64 Mbytes maximum 
ECC memory, 64 Kbytes instruction 
cache, 64 Kbytes data cache, 2.4 Gbytes 
maximum disk storage with the pedestal 
enclosure, 9.7 Gbytes maximum disk 
storage with the cabinet enclosure, 16.6 


integer MIPS processor speed, Mips 
Computer Systems’ R3000 CPU and 
R3010 floating-point chip, and a one- 
year warranty. Prices for a typical con¬ 
figuration are $49,900 (pedestal) and 
$74,400 (cabinet). 

Digital calls its DECstation 2100 a 
low-cost, color, RISC-based worksta¬ 
tion. It incorporates Mips Computer 
Systems’ R2000 and R2010 processors 
and runs at a clock speed of 12.5 MHz. 
It costs $11,450 for an 8-plane color 
system and $7,950 for an entry-level 
monochrome system, both with 8 
Mbytes of memory. 

5810, 5820; Reader Service 30 
5400: Reader Service 31 
2100: Reader Service 32 



Digital’s MicroVAX 3100 is software compatible with larger VAX systems. 


Digital offers low-cost VAX 

Digital Equipment claims that its 
MicroVAX 3100 is the lowest cost VAX 
computer able to handle multiple users. 
It replaces the MicroVAX 2000. The 
3100 comes in two enclosures: the com¬ 
pact Model 10 and the more expandable 
Model 20. 

Features include a CVAX processor 
chip; memory options of 4, 12, and 16 
Mbytes; SCSI storage peripherals; up to 
1.5 Gbytes of disk storage; 104- or 
332-Mbyte disk drives; Ethernet inter¬ 
faces; 4-12 asynchronous serial lines; 
one synchronous line; and VMS or 
Ultrix operating system. Options 
include external storage expansion 
boxes, an optical disk reader, a 3.5-inch 
floppy disk, and a streaming tape drive. 

Prices start at $8,480 for a minimum 


configuration Model 10 with 4 Mbytes 
of memory, a 104-Mbyte hard disk 
drive, a 1.4-Mbyte 3.5-inch floppy disk 
drive, four asynchronous lines, and 


five-user VMS OS and DECnet-VAX 
end-node software licenses. 

Reader Service 33 


High-end and midrange models expand Iris Power Series 


Silicon Graphics has expanded its Iris 
Power Series with the Power Center 
4D/280 arid the Iris 4D/210. The Power 
Center, the new high end of the series, 
is an eight-processor system that report¬ 
edly achieves 160 MIPS and 28 Mflops 
of sustained performance. The Iris 
4D/210, a midrange system, delivers 20 
MIPS and 3.3 Mflops. 

The Power Series systems are based 
on Mips Computer Systems’ R3000 


CPU, employ Silicon Graphics’ Power- 
path multiprocessing architecture, and 
run Irix, the company’s multiprocessing 
implementation of Unix. 

The Power Center 4D/280 comes in a 
62-inch high, 19-inch rack-mount chas¬ 
sis. Designed primarily as a server, it 
can house up to 4.8 Gbytes of disk stor¬ 
age, 128 Mbytes of ECC memory, and a 
variety of tape storage devices. An 
optional expansion chassis permits sup¬ 


port of up to 20.8 Gbytes of disk stor¬ 
age. The base price is $172,500. 

The Iris 4D/210 is based on a single 
25-MHz CPU/FPU. It features the 
GTX graphics subsystem. Prices for the 
4D/210GTX begin at $94,900. Prices 
for the 4D/210S server begin at 
$54,900. 

Shipments are scheduled for 
September. 
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Talking computers bypass keyboards, foster dialog with data 


Advanced Products & Technologies 
claims that its Voice computer allows 
you to have a dialog with your data. 

The company calls this process “con¬ 
versational computing.” You ask the 
Voice for information and it responds 
verbally. It can also display information 
on the 16-line by 24-character LCD flat- 
panel screen. 

This three-pound hand-held com¬ 
puter runs on a three-hour battery. A 
six-hour recharger is built into the unit, 
which also comes with an external 
universal power adapter. An RS-232 
serial communications port permits 
connection to PCs at 19,200 bps. 

The Voice computer relies on three 
microprocessors with 16- and 8-bit 
architectures. Each system has two cap¬ 
sule slots expandable to 1.3 Mbytes 
each for programmed data storage. 


According to the company, you can 
program the Voice for speaker depen¬ 
dent and independent voice recognition, 
depending on the application and size 
requirements of the vocabulary. The 
computer reaches a 60-word input rate. 

Among the software separately avail¬ 
able for the Voice computer, 
Nativeguide translation software report¬ 
edly recognizes more than 35,000 sen¬ 
tences spoken in English. The computer 
with the software installed translates 
and then speaks the phrase in a foreign 
language. The company plans to release 
modules in Spanish, French, Japanese, 
and Italian. 

Production of the Voice computer is 
scheduled for the end of 1989 following 
FCC certification. Pricing, although 
not set, should be around $2,000. 
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The Voice computer from Advanced 
Products & Technologies features a 
flat-panel screen that folds flat when 
not in use. 


Supercomputer features moderate parallelism 


Evans & Sutherland’s Computer 
Division has announced the ES-1, 
which it calls a moderately parallel 
supercomputer. According to the com¬ 
pany, the system provides scalar perfor¬ 
mance of 1,600 MIPS and floating¬ 
point performance of 1,600 Mflops. 

The ES-l’s architecture relies on four 
main subsystems: processors, shared 
memory, I/O, and disk. It comes with 
two to eight scalar processors and 
accommodates up to 2,048 Mbytes of 


physical main memory. Memory band¬ 
width equals 800 Mbytes per second, 
according to the company, while 
aggregate I/O bandwidth reaches 1,600 
Mbytes per second with the maximum 
eight I/O processors. The disk sub¬ 
system provides 8.5 to 450 Gbytes. 

The ES-1 runs the Esix operating sys¬ 
tem, an implementation of Berkeley 
Unix 4.3 BSD enhanced with Mach, an 
extension of BSD Unix developed at 
Carnegie Mellon University to support 


multiple processors. The company’s 
Esppre (E&S Parallel Programming 
Environment) reportedly allows users to 
build parallel applications or port exist¬ 
ing programs. 

The ES-1 ranges in price from $2.2 
million for a two-processor system to $8 
million for a fully configured eight- 
processor system. Shipments are sched¬ 
uled for this quarter. 

Reader Service 36 


NetSet 333 PC holds 33-MHz 386 


CASE benefits Ada 


Fortron/Source has announced the 
NetSet 333 PC. The system comes with 
a 33-MFIz 80386 processor, 1 Mbyte of 
memory, a 64-Kbyte cache of 15-ns 
static RAM, a 5X-inch 1.2-Mbyte floppy 
or a 3K-inch 1.44-Mbyte floppy disk 
drive, two serial and one parallel ports, 
ESDI controller, power suppy, 
documentation, and a tower chassis. 

The base price of $4,900 does not 
include the monitor and hard drive. 

The NetSet 333 expands up to 16 
Mbytes of memory and can incorporate 
an Intel 80387 or Weitek3167 
coprocessor. 

The company provides a one-year 
guarantee with on-site service, handled 
by Service Intelligence Corp. Fortron 
also provides a toll-free technical sup¬ 
port number. 
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Fortron’s NetSet 333 features a 33-MHz 
Intel 80386 processor in a tower 
configuration. 


TeleSoft AB has announced 
TeleArcs, a computer-aided software 
engineering product designed to 
improve productivity levels of Ada 
programmers, according to the com¬ 
pany. It is a programming environment 
for the TeleGen2 Ada Compilation Sys¬ 
tem, running on top of the Ada pro¬ 
gram library. 

Tools included in TeleArcs are an 
Ada language-sensitive editor, a brows¬ 
ing capability, interactive cross- 
referencing features, and a graphical 
display of the library structure of the 
system. 

Already marketed in Europe, 

TeleArcs costs $4,500 to $37,500 for 
VAX/VMS systems depending on con¬ 
figuration. TeleArcs for Sun-3 worksta¬ 
tions ranges from $4,500 to $5,250. 
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Wireless network relies on very high frequency radio waves 



O’Neill Communications’ LAWN uses spread-spectrum radio waves in a wireless 
local area network. 


O’Neill Communications offers a 
Local Area Wireless Network, or 
LAWN, that combines very high fre¬ 
quency radio transmissions with menu- 
driven communications software for 
electronic mail, file transfer, and 
peripheral sharing. LAWN units attach 
to the RS-232 serial port. 

Each LAWN includes a radio trans¬ 
ceiver, a microprocessor, memory for 
storing electronic mail when the com¬ 
puter is off, a 45-day battery backup 
for memory retention, and four radio 
channels. 

Secure transmissions result from the 
use of spread spectrum technology, sig¬ 
nal coding and decoding, and user- 
selectable security codes. The receiving 
LAWN must have the decoding algo¬ 
rithm and the correct security code to 
interpret data. 

According to the company, an error 
detection scheme with acknowledgment 
insures data integrity. The LAWN uses 
AX.25 (a version of X.25) data pack- 
etizing. Packets that do not prompt an 


acknowledgment of correct reception 
are re-sent. 

The LAWN, not the computer, moni¬ 
tors network traffic. Also, spooling 
allows background transfer of data. 

LAWN units retail for $495 per node. 


They are currently available for IBM 
PCs, with a Macintosh version planned 
for late 1989. The company provides a 
toll-free technical support number. 
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BBN tackles time-critical applications with TC2000 


BBN Advanced Computers said that 
it designed the TC2000 system specifi¬ 
cally for time-critical applications. The 
new system incorporates Motorola’s 
88000 RISC microprocessor and fea¬ 
tures a multiprocessing architecture that 
reportedly allows expansion in the field 
from eight to 504 processors with cor¬ 
responding increases in memory, 
memory-access bandwidth, and I/O 
capabilities. 

The TC2000 relies on a function card 
design and Butterfly switch technology, 
according to the company. Each func¬ 
tion card includes the CPU, memory, 
and optional I/O capabilities (VME- 
bus). BBN claims that its function cards 
provide 19 Dhrystone MIPS and 13 
megaWhetstones of performance. They 
also provide up to 32 Mbytes of DRAM. 

The TC2000 supports two operating 
systems concurrently: the PSOS + m 
real-time executive and the nX operat¬ 
ing system, based on Unix 4.3 BSD. 

The system’s software-controlled 
clustering capability allows users to 
assign processors to groups or clusters, 
which are then designated for either nX 
or PSOS + m operation. According to 
the company, different sections of an 
application can be run concurrently on 
each, and data can be shared within and 
between clusters. 

Prices begin at $350,000 for a base 


model. The TC2000 comes with the 
Xtra graphical development system, 
based on the X Window system, plus a 
debugger and graphics-oriented perfor- 

ALR bases PC on i486 

Advanced Logic Research has based 
its PowerCache 4 on Intel’s i486 
microprocessor. The new PC is compat¬ 
ible with IBM’s Micro Channel. It uses 
a 128-Kbyte read and write-back cache 
design, according to the company. The 
read cache supports the i486’s burst 
cacheable cycles, reportedly delivering a 
better than zero wait-state performance 
by transferring 32 bits of data in one 
clock cycle. 

PowerCache 4 systems come with 2 
Mbytes of RAM expandable to 32 
Mbytes, a 1.44-Mbyte PS/2-compatible 
floppy disk drive, and hard disk. Disk 
capabilities range from 130 Mbytes in 
the desktop system, while multiple drive 
configurations up to 1.2 Gbyte are 
available in the floor-standing chassis. 

The system features VGA graphics 
with a resolution of 640 x 480 pixels, 
supporting 16 colors. 

Prices start at $9,990. Shipments are 
scheduled for September. 


mance analyzer. Volume shipments are 
scheduled for September. 
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Ada compiler generates 
88000 code 

Altech Software Engineering has 
announced the AI-Ada/88K Cross 
Compiler System for Motorola 
88000-based embedded systems, specifi¬ 
cally Motorola’s MVME180 board. 
Hosted on Digital Equipment VAX 
computers running VMS, the compiler 
generates 88000 code. It includes a cross 
compiler, a program library manager, 
an Ada cross linker, 88000 cross assem¬ 
bler utilities, a monitor/debugger, and 
a runtime executive. 

The AI-Ada/88K is a multipass com¬ 
piler. Several passes (optimizations) are 
optional and under the user’s control, 
according to the company. Code 
produced by the compiler is linked to 
the runtime executive AI-ARTOS/88K, 
which supports Ada execution-time 
requirements. 

Prices for the AI-Ada/88K start at 
$20,000 and depend on the hardware 
configuration. 
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Zenith debuts its smallest, lightest portable 



Zenith Data Systems says that the 
new Minisport is its smallest, lightest 
PC at less than six pounds. It measures 
12.4x9.8 x 1.3 inches. 

The portable features an 8/4.77-MHz 
switchable 80C88-2 microprocessor, a 
9/-inch backlit screen, a removable and 
rechargeable NiCad battery pack with 
Intelligent Power Management, an AC 
adapter/charger, a 9-pin serial port, a 
25-pin parallel port, an RGBi video 
port, a 20-pin floppy disk drive port, an 
internal modem slot, data transfer soft¬ 
ware, and an 80-key keyboard. 

Model 1 comes with 1 Mbyte of 
RAM, of which 360 Kbytes can be set 
as a battery-backed silicon disk expand¬ 
able up to 1.36 Mbytes. Model 2 comes 
with 2 Mbytes of RAM and a 
1.36-Mbyte silicon disk. MS-DOS 3.3 
Plus and a data transfer program come 
stored in the 832 Kbytes of ROM. 

The Minisport also uses 2-inch 
Minidiskettes, which hold 720 Kbytes of 
data. The battery operates for three 
hours and recharges in 4-6 hours. 

Model 1 costs $1,999 and Model 2, 
$2,799. 
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Ada bound to RDBMSs 

Compass claims that its Ada SQL 
Binding allows developers to use rela¬ 
tional database management systems 
with Ada application programs while 
adhering to the Ada standard. The 
Binding reportedly supports the SQL- 
Ada interface developed by the Soft¬ 
ware Engineering Institute’s SQL-Ada 
Module Extensions Design Committee 
and conforms to the ANSI standard 
Ada-SQL binding. 

Compass’ binding consists of the 
Compass Ada SQL Module Compiler 
and its runtime library, the Compass 
Ada Programming Interface. 

According to the company, the Mod¬ 
ule Compiler is RDBMS independent. 
The Ada that it generates consists 
primarily of calls to the Ada Program¬ 
ming Interface. The API provides the 
portability layer for retargeting the 
binding to another RDBMS. Compass 
takes care of those changes. 

The Compass Ada SQL Binding 
started Beta testing in October 1988. 
Prices vary based on the number of 
development licenses and end-user 
license required, and on the hardware 
and software combination. 
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Series 6000 models contain 
ASIC technology 

McDonnell Douglas says that its new 
Series 6000 models incorporate proces¬ 
sor and memory architecture based on 
CMOS application-specific integrated 
circuit technology designed by McDon¬ 
nell Douglas and implemented by LSI 
Logic. Each ASIC chip reportedly sup¬ 
ports 100,000 logic gates. In the new 
models, a single ASIC-based board 
replaces up to four CPU and memory 
boards. 

Model 6404 includes the company’s 
proprietary CPU, 2 Mbytes of memory, 
a 75-Mbyte ESDI, a 120-Mbyte car¬ 
tridge tape drive, and eight ports. It 
comes in a tower cabinet for $27,900. 

Model 6604 includes the CPU, 2 
Mbytes of memory, 2 Mbytes of cache, 
a 150-Mbyte ESDI, a dual-density 
Jfinch PE tape drive, and 16 ports. It 
comes in a low-boy cabinet for $51,500. 

Model 6402 replaces Model 6401. It 
costs $20,900 for 1 Mbyte of memory, a 
75-Mbyte ESDI, a 120-Mbyte cartridge 
tape drive, and eight ports in a tower 
cabinet. 

Model 6602 replaces Model 6600. It 
costs $44,500 for 2 Mbytes of memory, 

2 Mbytes of cache, a 150-Mbyte ESDI, 
a dual-density /-inch PE tape drive, and 
16 ports in a low-boy cabinet. 

Series 6000 models come with the 
Reality operating system loaded in 
firmware. 

Models 6404 and 6604 are scheduled 
for shipment in October. Models 6402 
and 6602 are available now. 
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Embedded PCs for VMEbus 
based on 386SX chip 

Radix Microsystems has announced 
the EPC-3 line of embedded personal 
computers based on Intel’s 80386SX 
CPU. The products come in a VMEbus 
form factor. 

The EPC-3 CPU module includes the 
CPU, up to 4 Mbytes of DRAM, 
optional numeric coprocessor, serial 
and parallel I/O, keyboard interface, 
and a VGA graphics controller. It also 
includes a VMEbus interface with 
system-controller functions. 

EPC-3 expansion modules include 
four options for mass storage: a VME¬ 
bus form factor 40-Mbyte hard disk and 
3/-inch floppy drive unit, a LAN inter¬ 
face with software for diskless opera¬ 
tion, a solid-state disk module, and a 
disk interface module for connection to 
external disk drives. 

EPConnect 3.0 VMEbus software 
includes three programs for hardware 
system configuration, system test, and 
system debug. It also contains runtime 
programs for VMEbus accesses, VME¬ 
bus auxiliary processor communica¬ 
tions, and I/O drivers for certain 
VMEbus boards. 

OEM prices (in 100s) are $2,595 for 
the EPC-3 CPU module with 1 Mbyte 
of DRAM, $850 for the EXP-MS mass 
storage module, $380 for the EXM-1 
Ethernet module, $590 for the EXM-2 
solid-state disk with 1 Mbyte of storage, 
$260 for the EXM-3 disk interface for 
external drives, and $300 for EPCon¬ 
nect 3.0 software. 
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RTSS-89 

Tenth Real-Time Systems Symposium 
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Santa Monica, CA 



^ IEEE Computer Society 
TC Real-Time Systems 


jf the design, development, ai 
sir: Prof. AI Mok, University of Texas 
Program Chair: Dr. Doug Locke, IBM 


Tuesday, December 5 


Welcome 


Seaslon 1 : Resource Scheduling and Allocation I 

• Minimizing Mean Flow Time with Error Constraint, 
Joseph Leung, Tommy W. Tam, C.S. Wong, 

• Fast Algorithms for Scheduling Imprecise 
Computations with Timing Constraints, Jen-Yao 
Chung, Wei-Kuan Shih, Jane W. S. LIu 

Session 2: Language Issues 

• Events: A Structuring Mechanism for a Real- 
Time Runtime System, Marc Donner, David 
Jameson, William Moran, Jr. 

• An Experiment In the Deterministic Scheduling of 
Ada Tasks, Edward W. Glaring III, Ted Baker 

• A Distributed Real-Time Language and Its 
Operational Semantics, Padmanabhan Kriehnan, 
Richard Volz 


• Transient Overloads In Fault-Tolerant Real-Time 
Systems, Philip M. Thambldural, Klshor S. Trivedl 

• Algorithm-Based Fault Tolerance for Signal 
Processing Applications on a Hypercube 
Multiprocessor, Prlthvlraj Baneijee, Vl|ay 

• Experimental Evaluation of Real-Time 
Transaction Processing, John A. Stankovlc, 
Jiandong Huang, Don Towsley, Krithi 


• Nearly Poisson Traffic In Real-Time Networks, 
Dave Craig, C.M. Woodslde 

• Scheduling Parallellzable Jobs on 
Multiprocessors, KwekJay Lin, Chlng-Chln Han 

• Communication Shared Resources: A Model for 
Distributed Real-Time Systems, Insup Lee, 
Richard Gerber 

• Token-Ring Adapter-Chipset Architectural 
Considerations tor Real-Time Systems, Thomas 
E. Marc ho k. Jay K. Strosnkfer, Hldeyukl Tokuda 

Session 4: Reasoning About Time I 

• Real-Time Temporal Logic Decision Procedures, 
Jonathan Ostroff 

• A Framework for Reasoning About Time and 
Reliability, Hans Hansson, Bengt Jonsson 

• A Transformational Method for Verifying Safety 
Properties In Real-Time Systems, Armen 


Session 6: Resource Scheduling and Allocation II 

• Performance Analysis of FCFS and Improved 
FCFS Scheduling Algorithms tor Dynamic Real- 
Time Computer Systems, Wei Zhao, John A. 

• The Rate Monotonlc Scheduling Algorithm: 

Exact Characterization and Average Case 
Behavior, John P. Lehoczky, Lul Sha, Ye Ding 

• Application of Real-Time Monitoring to 
Scheduling Tasks with Random Execution Times, 
Dieter Haban, Kang G. Shin 

Session 7: Real-Time Software Architecture I 

• SPARTA: Signal Processor Architecture for 
High-Performance Real-Time Applications, 
Jehuda Ish-Shalom, Peter Kazanzidas 

• Object-Oriented Design of Real-Time Software, 
Prabha Goplnath, Thomas Blharl, Karsten 


• A Framework for Specification and Design of 
Muntz, Ellis Horowitz 

• A Distributed Faut Tolerant Architecture for 
Nuclear Reactor Control and Safety Functions, 
Myron Hecht, Jeffry Agron, Sara Hochhauser 

• A Fault-Tolerant Microcomputer for Advance 
Control: Architecture and Performablllty Analysis, 
Calln Sandovlcl, Cristlan Constantinescu 

• SMART (Strategic Memory Allocation for Real- 
Time) Cache Design, David B. Kirk 


• A Decomposition Approach to Nonpreemptlve 
Scheduling In Hard Real-Time Systems, Xiaoping 
Yuan, Ashok K. Agrawala 

• From Synchronous Irrtenslonal Programming to 
Efficient Implementation, Bernard Le Goff, 

Thierry Gautier 

• A Tasking Model for Reactive Systems, 

Vered Gafni 

Session 10: Resource Scheduling and Allocation III 

• Time Bounds for Real-Time Process Control In the 
Presence of Timing Uncertainty, High Attiya, 

Nancy A. Lynch 

• Greed tn Resource Scheduling, Donald W. Gillies, 
Jane W. S. Uu 

• Analysis of a Synchronization and Schedulng 
Discipline for Real-Vme Tasks with Preemption 
Constraints, Kevin Jeffay 

Session 11: Reasoning About Time H 

• Formal Analysis of Real-Time Equatlonal Rule- 
Based Systems, AI Mok 

• Verifying Properties of Systems with Variable 
Timing Constraints, Famam Jahanian 

S es si on 12: Distributed Processing II 

• A New Probabilistic Algorithm for Clock 
Synchronization, K. Arvlnd 

• Real-Time File Performance of a Completely 
Decentralized Adaptive File System, Horst F. 
Wedde, Dorota Baran, Gookhal Kang, 

Bo-Kyung Kim 

• Priority Inversions In Real-Time Communication, 
Hldeyukl Tokuda, Clifford W. Mercer, Yutaka 
Ishlkawa, Thomas E. Marchok 

• Some Properties of Double-Ring Networks with 
Real-Time Constraints, Adriano Valenzano, 

hi, L. Clminlera 


For hotel reservations contact: 

Loew^ Santa Monica Beach Hotel 
1700 Ocean Avenue 
Santa Monica, CA 90401 
(213) 468-6700 

(Be sure to request the conference ral 


Honeywell Systems and Research Center 

MN65-2100 

3660 Technology Drive 

Minneapolis, MN 55418-1006 

(612)782-7332 


IEEE Member $180 $ 

Non-Member $225 $ 

Full-Time Student $70 i 

Make checks payable to IEEE Tenth RTSS 
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1C Announcements 


Company, Model, Function Comments R.S, No. 


Gould 

Compiled RAMs 
RAMs on gate arrays 


Compiled RAMs that can be implemented on gate array circuits. Configurable to handle be- 120 
tween 32 and 1,024 data words and word sizes between one and 16 bits. Available in PLCCs, 

DIPs, quad flatpacks, and ceramic packages. Cost (5,000 gate arrays/year): from $4-$50 with 
1,000-20,000 gates. 


Gould 

631000 series 
ROMs 


One-Mbit ROMs with 150- and 200-ns response times. Require a 5V power supply. Feature up 121 
to four user-definable control pins. Come in 28- and 32-pin DIPs and 32-pin surface mount 
PLCCs. Operate over commercial, industrial, and military temperature ranges. Cost 
(10,000s): starts at $5.50. 


Hitachi America 
HG29A32 
Gate array 


A gate array with TTL-compatible I/O. Operates at a clock speed of 160 MHz. Has 3,000 gates, 122 
102 I/O pins, and a 0.45- ns internal propagation delay for two-input NAND gate. Comes in a 
120-pin PGA. Cost (5,000s): $75, with NRE charges from $20,000-$60,000. 


Hitachi America 
HG21T30 
Gate array 


A gate array that supports both ECL and TTL logic interfaces. Operates at a clock speed of 200 123 

MHz. Has 3,000 gates, 90 I/O pins individually selectable to be ECL or TTL compatible, and a 
0.45-ns internal propagation delay for a two-input NAND gate. Comes in a 120-pin PGA. Cost 
(5,000s): $125, with NRE charges from $20,000-$60,000. 


Integrated Device 
Technology 
IDT7381/3 
ALUs 


Two 16-bit, cascadable arithmetic logic units operating at 25 ns and with three buses. IDT7383 124 
has 32 instructions. IDT7381 is a faster version of industry standard, pin-compatible devices. 

Both come in 68-pin PLCCs and PGAs. Cost (100s): $23.50 for IDT7381 in PLCC; $28.20 for 
IDT7383 in PLCC. 


Intel 

82350 

EISA chip set 


A chip set to implement the 32-bit Extended Industry Standard Architecture. Includes the 125 

82357 integrated system peripheral, 82358 EISA bus controller, 82352 bus buffer, and 82355 
bus master interface controller. Cost (1,000s): $99 (25 MHz) and $120 (33 MHz) for 82357 and 

82358 set; $35 for 82355; $18.75 for 82352 (samples in September). 


Intel 

82596 

LAN coprocessor 


A family of 32-bit LAN coprocessors. Offloads the host CPU and transfers data at the 32-bit 126 
bandwidth of the system bus. Supports all Intel 32- and 64-bit processors. Features direct inter¬ 
face to the CPU, burst bus data transfer, a 192-byte internal FIFO, and bus throttles. Cost 
(1,000s): $88 for 82596CA; $65 for 82596DX; $53 for 82596SX. 


Lattice Semiconductor 
GAL16V8A-15/883C, 
GAL20V8A-15/883C 
PLDs 


Programmable logic devices compliant with Mil-Std-883C. Operate at 15 ns and consume 75 127 

mA typical Icc. Can emulate more than 42 different programmable array logic devices. 

GAL16V8A emulates 20-pin PALs; GAL20V8A emulates 24-pin PALs. Available in 15-, 20-, 
and 30-ns versions, in ceramic or sidebrazed DIPs. Cost (100s): start at $10.62. 


Motorola 
33.33-MHz 88000 
RISC microprocessors 


A 33.33-MHz speed version of the 88000 reduced instruction set computer microprocessor 128 
family, now sampling. Processes 28 MIPS. Delivers 64,500 Dhrystones and 33,000 KWhet- 
stones. Scaled to a 1.2-micron technology. Cost (samples): $894 for 88100; $1,171 for 88200. 


NEC Electronics 

UPD77220 

DSP 


Precision Monolithics 

OP-61 

Op amp 


A 24-bit fixed-point digital signal processor. Provides a 47-bit, 8-register fixed-point ALU 129 
with instruction ROM of 2K words x 32 bits and a data ROM of IK words x 24 bits. Processes 
arithmetic operations in a single cycle at a rate of 122 ns. Operates in master or slave mode. 

Comes in 68-pin PGAs and PLCCs. Cost (10,000s): $45. 

A low-noise (3 nVVHz at 1 KHz) operational amplifier with a gain-bandwidth of 200 MHz at 1 130 

MHz. Has an open-loop gain of 400V/mV and offset voltage of 200 pV typical. Comes in 8-pin 
ceramic DIPs, plastic DIPs, and 20-contact LCCs. Cost (100s): starts at $4.25 industrial, 

$15.80 military. 


Saratoga Semiconductor Three 12-ns, 16-Kbit density SRAMs with TTL I/O interface. SSM6116 is organized 2Kx8 131 

SSM6116/68/70 with common data I/O. SSM6168 and SSM6170 are 4Kx4 with common data I/O. SSM6170 

SRAMs has an output enable function. The SRAMs come in a variety of packages. Cost (1,000s): starts 

at $20.80 for SSM6170 (PDIP). 


Silicon Composers 
SC32 

Stack-Chip CPU 


A 32-bit Stack-Chip microprocessor that delivers 10 MIPS at 10 MHz and can be software con- 132 
figured to handle up to 50 MIPS in burst mode. Optimized for embedded control applications. 

Uses 34,000 transistors packaged in an 85-pin PGA. Cost: $395 ($295 for 8-MHz SC32-8). 
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Company, Model, Function 

Comments R.S. No. 

American Megatrends 
Amidiag 

Diagnostic utility 

A menu-driven diagnostic utility for 80286- and 80386-based IBM PCs and compatibles. 135 

Tests hardware subsystems, including motherboard, memory, hard disk drives, floppy disk 
drives, keyboard, video adapter, monitor, printer port, and serial port. Cost: $99. 

Applied Microsystems 

EL 3200 

Emulator 

An in-circuit emulator for 32-bit microprocessors running at 33 MHz and faster. Supports 136 

68030 cache burst and synchronous bus cycles. Runs on Sun workstations and PCs. Cost: starts 
at $22,000 for 68020, $26,000 for 68030. 

AST Research 

Fastboard 486/25 
i486 upgrade 

An ISA-based i486 CPU upgrade for 25- and 33-MHz Premium 386 computers. Includes cache 137 
controller, partial system memory, and sockets for optional numeric coprocessors on a 32-bit 
plug-in CPU card. Cost: $2,995 386/33 upgrade; $3,695 for 386/25 upgrade. 

Bit 3 Computer 

Model 453 Adaptor 

NuBus VME adaptor 

A NuBus to VME adaptor that makes the Apple Macintosh appear as a bus master processor on 138 
the VMEbus. Consists of two printed circuit cards, one inside the Mac and the other inside a 

VMEbus card cage. Uses a memory mapping scheme to allow the Mac to access 24 bits of VME 
address space. Cost: $1,480. 

Burr-Brown 

ZPB3201/02 

DSP boards 

DSP boards interfaced to the VMEbus through parallel ports. ZPB3201 uses a 25-MHz AT&T 139 
WE DSP32-160 floating-point processor with 64 Kbytes of SRAM and buffered serial I/O 
ports. ZPB3202 has two DSP32-160 processors. Both boards come in standard 6U VME for¬ 
mats. Cost: $2,995 for ZPB3201; $4,495 for ZPB3202. 

Cache Computers 
SX386-20 

Motherboard 

A motherboard based on Intel’s 16- or 20-MHz 80386SX CPU. Has 32-bit software compati- 140 

bility, but functions with a 16-bit AT external bus. Features a 4-Gbyte address space, support 
of the virtual 86 mode, and multitasking. Up to 8 Mbytes of memory on-board. Cost: $475 with 

0 memory; $695 with 1 Mbyte of memory. 

Global Specialties 
Proto-Board PB-204 
Prototyping system 

A prototyping workstation for circuit design. Has a triple voltage power supply of 5V, 12V, 141 

and -12V for op amp, microprocessor, TTL, and CMOS designs. Breadboarding area has 

2,250 tie points, with space for up to 24 14-pin DIPs. Cost: $119.95. 

Hewlett-Packard 

DeskWriter 

Printer 

An ink-jet printer for Apple Macintosh computers. QuickDraw-based, with font-scaling tech- 142 
nology. Comes with four screen-font families and corresponding outline printer fonts. Addi¬ 
tional typefaces available. Has a one-year warranty. Cost: $1,195. 

IBM 

PS/2 Enhanced 80386 
Memory Option 

A memory expansion card for the PS/2 Model 70, P70, and 80. Uses 1-Mbit and 4-Mbit chips. 143 

Cost: $1,795 for 2-Mbyte card, available now; $3,495 for 4-Mbyte card and $3,095 for 4- 
Mbyte memory modules, both available in first quarter 1990. 

Mercury Computer 
Systems 

MC6400VS 

Attached processor 

A triple-height, 9U form factor, attached processor with up to 64 Mbytes of on-board memory 144 
for Sun-3 and Sun-4 workstations. Runs at an 80-ns clock speed using the Weitek XL8364 chip 
set. Cost: starts at $25,000 for 16-Mbyte system, including compiler development package and 

VAST-2 Fortran precompiler. 

Pacific Microcomputers 
PM683 

SBC 

A 68030-based single-board computer with a Sun-style memory management unit. Comes 145 

with up to 8 Mbytes of on-board memory plus 1 Mbyte of EPROM. Features flexible window¬ 
ing. Has seven cross memory mailbox interrupts and two serial I/O channels capable of syn¬ 
chronous or asynchronous operation. Cost: $3,975. 

Pioneer Computer 
Vantage 386SX 
Motherboard 

A 20-MHz 80386SX motherboard with a rating of 25.4 on the Landmark Speed Test and 3.44 146 

on MIPS. Includes shadow RAM, up to 8 Mbytes of on-board memory, LIM EMS 4.0 memory 
support, and 80387SX math coprocessor support. Cost: $395 with 0 memory. 

Silicon Composers 

SC/Fox SBC 

SBC 

A Eurocard-size single-board computer based on the Harris RTX 2000 microprocessor. In- 147 

eludes an RS-232 serial port, Centronics parallel port, reset switch, 64 Kbytes of shadow 

EPROM, and up to 512 Kbytes of zero-wait state SRAM. Comes with FCompiler development 
software. Cost: $1,495 for 8-MHz system with 64 Kbytes of SRAM. 

Total Systems 

Voyager 030/33 
Accelerator card 

A 33.3-MHz 68030 accelerator card for the Macintosh II/IIx. Manufactured by Siclone Sales 148 
and Engineering. Bundled with Control Panel, scrolling speed, TurboOptimizer, Turbo- 
Cache, and Virtual software. Cost: $4,195; $5,195 with 68882 option. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 

In order to conform to the Age Discrimi¬ 
nation in Employment Act and to dis¬ 
courage age discrimination, COMPUTER 
may reject any advertisement containing 
any of these phrases or similar ones: 
“...recent college grads...,” “...1-4 years 
maximum experience.up to 5 years 
experience...,” or “...10 years maximum 
experience." COMPUTER reserves the 
right to append to any advertisement, 
without specific notice to the advertiser, 
“Experience ranges are suggested mini¬ 
mum requirements, not maximums.” 
COMPUTER assumes that, since adver¬ 
tisers have been notified of this policy in 
advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


UNIVERSITY OF 
COLORADO / BOULDER 

The Department of Electrical and Com¬ 
puter Engineering is seeking a quality tenure- 
track faculty member to further enhance its 
research and educational activities in Com¬ 
puter Engineering. The successful candidate 
must have an outstanding academic record 
and significant achievement in original re¬ 
search as well as interest in undergraduate 
and graduate education. A Ph.D. degree in 
Electrical Engineering, Computer Engineer¬ 
ing, Computer Science or other related field 
is required; salary will be commensurate with 
qualifications and experience. Preference 
will be given to candidates at the Assistant 
Professor level but candidates at all levels will 
be considered. Areas of specialization in¬ 
clude, but are not necessarily limited to, Soft¬ 
ware Engineering, Programming Languages, 
Operating Systems, Hardware/Software In¬ 
terface and Computer Architecture. 

The University of Colorado at Boulder has 
a strong institutional commitment to the prin¬ 
ciple of diversity in all areas. In that spirit, we 
are particularly interested in receiving appli¬ 
cations from a broad spectrum of people, in¬ 
cluding women, members of ethnic minori¬ 
ties and disabled individuals. 

Applications for this position should be 
sent to: Prof. Frank S. Barnes, Dept, of Elec¬ 
trical and Computer Engineering, University 
of Colorado, Campus Box 425, Boulder, 
CO 80309-0425. Deadline for application is 
October 31, 1989. 


FLORIDA STATE UNIVERSITY 
Department of Computer Science 

Applications are invited for tenure track 
faculty positions at all levels in the Depart¬ 
ment of Computer Science. Areas of special 
interest include, but are not limited to, 
operating systems, programming languages, 
computer graphics, software engineering, 
and computer architecture. 

Our department is a young and rapidly 
growing one. It offers B. S., M. S., and Ph. D. 
degrees, and it places a strong emphasis on 
excellence in research and teaching. Re¬ 
search facilities include a supercomputer 
ETA 10, a CYBER 205, a CYBER 850, a 
graphics lab, and a local network consisting 
of a VAX 11/780, a VAX 11/750, several 
SUN workstations, and Symbolics 3640. 

Applicants should have a Ph.D. in com¬ 
puter science or a closely related area, and a 
strong commitment to teaching and research. 

Send resume and names of at least three 
professional references to: 

Dr. Abe Kandel, Chairman 
Department of Computer Science 
Florida State University 
Tallahassee, FL 32306-4019 
Florida State University is an Equal Op¬ 
portunity Affirmative Action Employer. 


UNIVERSITY OF ALBERTA 

Department of Computing Science 

Applications are invited for two tenure- 
track positions at the Assistant/Associate/ 
Full Professor levels. Responsibilities include 
research as well as teaching at both the grad¬ 
uate and undergraduate levels. Strong can¬ 
didates from all research areas will be con¬ 
sidered. 

This young and energetic department has 
recently undergone significant expansion 
and consists of 36 academic and 29 support 
staff. Current hardware support for research 
includes a time sharing network of MIPS M/ 
1000 and VAX 11/780L/C connecting 36 
Sun workstations and a large number of ter¬ 
minals. Well-supported laboratories exist for 
AI, database, distributed systems, graphics, 
image processing, programming languages 
and robotics research. Access to a Cyber 205 
is available. 

The current salary range is $C34,970 to 
$C80,000+ with the appointment level 
being commensurate with qualifications and 
experience. Send curriculum vitae, the 
names of three references and up to three 
reprints or copies of important publications. 
New Ph.D.’s should also include a copy of 
their transcript. Apply to: 

Dt. Paul G. Sorenson 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta, Canada 
T6G 2H1 

Applications will be accepted until Janu¬ 
ary 31, 1990. 

The University of Alberta is committed to 
the principle of equity employment. 


UNIVERSITY OF HONG KONG 
Senior Lecturer/Lecturer in Electrical 
and Electronic Engineering 

Applications are invited for a Senior Lec¬ 
tureship/Lectureship in the Department of 
Electrical and Electronic Engineering. Ap¬ 
plicants should possess a higher degree, 
and/or corporate membership of the Institu¬ 
tion of Electrical Engineers or its equivalent. 
Preference will be given to those having 
teaching, research and other relevant ex¬ 
perience in the fields of Computer Com¬ 
munications or Physical Electronics. 

Annual salaries (superannuable) (under 
review) are on the scales; Senior Lecturer 
HK$320,280 - 430,260 (9 points) (approx. 
£26,250 - 35,270); Lecturer HK$206,040 
-344,400 (11 points) (approx. £16,890 
-28,230). (Sterling equivalent as at June 29, 
1989.) Starting salary will depend on qualifi¬ 
cations and experience. At current rates, 
salaries tax will not exceed 15% of gross in¬ 
come. Children’s education allowances, 
leave, and medical benefits are provided; 
housing or tenancy allowances are also pro¬ 
vided in most cases at a charge of 7V2% of 

Further particulars and application forms 
may be obtained from Appointments 
(36612), Association of Commonwealth 
Universities, 36 Gordon Square, London 
WC1H OPF UK, or from the Appointments 
Unit, Registry, University of Hong Kong, 
Hong Kong. Applicants are additionally re¬ 
quested to provide, in respect of their major 
research area: a short descriptive title; and a 
brief summary of the work they have under¬ 
taken and the direction in which their work is 
proceeding. 

Closes 29 September 1989. 


UNIVERSITY OF WISCONSIN- 
MADISON 
Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure and tenure-track positions. A Ph.D. 
degree is required, and successful candi¬ 
dates are expected to participate in both 
teaching and research activities. Applicants 
in all areas of computer engineering are in¬ 
vited to apply, but the following areas are of 
special interest: computer architecture, com¬ 
puter networks, VLSI and computer-aided 
design, microprocessor and minicomputer 
applications, real-time control and in¬ 
strumentation applications, and engineering 
applications of artificial intelligence. Rank 
and salary will be commensurate with qualifi¬ 
cations and experience. Send resume and 
names of three references to J. Leon 
Shohet, Chairman, Department of Electrical 
and Computer Engineering, University of 
Wisconsin-Madison, 1415 Johnson Drive, 
Madison, WI 53706, an equal opportunity/ 
affirmative action employer. 
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CARNEGIE MELLON UNIVERSITY 
Faculty Positions in 
Computer-Aided Engineering 

Carnegie Mellon University, Department 
of Civil Engineering, invites applications for 
(1) tenure-track position at the rank of Assis¬ 
tant Professor or above, and (1) visiting 
faculty position in the area of Computer- 
Aided Engineering (CAE). The tenure-track 
position will begin either January or Septem¬ 
ber, 1990. The visiting position runs from 
January thru December, 1990, and may be 
filled by two individuals, one from January 
through May 15, and one from August 15 
through December. Candidates for either 
position must have an earned Ph.D. (or 
equivalent experience for the visiting posi¬ 
tion), with research and educational em¬ 
phasis on CAE in civil engineering. The De¬ 
partment offers programs in CAE, engineer¬ 
ing planning and management (including 
construction automation), environmental 
engineering, and structural mechanics. 
Within CAE, areas of special interest include 
artificial intelligence, knowledge-based sys¬ 
tems, database management, parallel com¬ 
putations, design methodology, graphics, 
user-interfaces, visualization, geometric 
modeling and large-scale systems design. 
Candidates for the tenure-track position 
should also have interests in one of the other 
areas of the department. Those with interests 
in planning and management or environmen¬ 
tal engineering are especially encouraged to 
apply. Tenure-track responsibilities include 
teaching of undergraduate and graduate 
courses in CAE and other areas of civil engi¬ 
neering, advising students, developing curri¬ 
culum, supervising research and graduate 
students, and establishing a funded research 
program. Visiting faculty will teach 1 course 
per semester in CAE and participate in on¬ 
going research activities. CAE activities are 
well established, and the department offers 
excellent facilities and opportunities for pro¬ 
fessional and intellectual growth. The de¬ 
partment maintains close ties with the uni¬ 
versity’s Robotics Institute, the School of 
Computer Science and with the CMU Engi¬ 
neering Design Research Center. Send ap¬ 
plication with curriculum vita and names of 
at least three references to: Daniel R. Rehak, 
CAE Faculty Search Committee, Depart¬ 
ment of Civil Engineering. Carnegie Mellon 
University, Pittsburgh, PA 15213-3890. IN¬ 
TERNET: REHAK@CE.CMU.EDU. Clos¬ 
ing date for applications is October 1, 1989, 
or until the position is filled. Carnegie Mellon 
is an equal opportunity/affirmative action 
employer. 


PURDUE UNIVERSITY 
Computer Engineering 
Faculty Positions 

The School of Electrical Engineering at 
Purdue University seeks outstanding candi¬ 
dates in all areas of Computer Engineering 
for research and teaching. Openings are for 
tenure-track faculty at all levels. Active 
research areas include artificial intelligence 
and expert systems; computer communica¬ 
tion networks; computer vision; design 
automation tools; digital signal processor 


system design; distributed algorithms and 
databases; fault-tolerant and testable com¬ 
puting; microprocessor design; neural net¬ 
works; parallel processing (architecture, al¬ 
gorithms, operating systems, compiling, 
languages, interconnection networks, and 
performance); robot vision, sensors and 
control; software engineering; speech pro¬ 
cessing; and VLSI architecture. 

The School has 68 full-time faculty (25 in 
Computer Engineering), and over $9M in 
funded research projects. In addition to the 
Ph.D., MSEE, and BSEE degrees, the 
School offers a BSCEE (Bachelor of Sci¬ 
ence in Computer and Electrical Engineer¬ 
ing) which is accredited in both Computer 
Engineering and Electrical Engineering. 
Computing facilities available to the faculty 
include the Engineering Computer Net¬ 
work (including 13 VAX 11/780’s running 
UNIX BSD 4.3,1 Gould PN 9080,4 Gould 
NP l’s, a CCI PN 6/32, and 255 Sun work¬ 
stations), the Computing Center’s Cyber-205 
and ETA-10 supercomputers, a Symbolics 
LISP machine, and IBM 3090/180E, exten¬ 
sive graphics facilities, and numerous PC’s. 
Parallel computing facilities include a 128- 
node Ncube hypercube, a 48 x 48 processor 
NCR-GAPP processor array, a 16 processor 
Transputer array, the 30-processor PASM 
Parallel Processor prototype that was devel¬ 
oped and built at Purdue, and the Com¬ 
puting Center’s Sequent Balance 21000. 
Custom VLSI chip facilities include an IBM 
Master Image System. Equipment in the 
Robot Vision Lab and Computer Vision and 
Image Processing Lab includes a Puma 762 
robot, a Cincinnati Milacron T3-726 robot, a 
K2A Cybernation mobile robot, and Gould/ 
DeAnza, Comtal, Grinnell, and Imaging 
Technologies image processing systems. 

Applicants must possess a doctorate 
degree. Send a resume, including a state¬ 
ment of teaching and research interests and 
a list of three (3) references, to: Head, 
School of Electrical Engineering, Purdue 
University, West Lafayette, IN 47907. Pur¬ 
due University is an Equal Opportunity/Af¬ 
firmative Action employer. 


ASTEM, KYOTO, JAPAN 
Research Positions in CAD and 
Knowledge Engineering 

The newly established Advanced Soft¬ 
ware and Mechatronics Research Institute 
(ASTEM), Kyoto, Japan, invites applica¬ 
tions for research and research associate 
positions. Speciality areas include, but are 
not limited to, LSI CAD, 3D CAD, and 
knowledge engineering. For a research asso¬ 
ciate position, a candidate should be highly 
qualified and hold an MS in CS, EE, or re¬ 
lated fields; for a research position a Ph.D. is 
normally required. ASTEM provides an ex¬ 
cellent environment for research in Software 
Engineering and AI with unique Japanese 
software and dedicated SUN4 and SUN3 
workstations. 

ASTEM is located in Kyoto, the ancient 
beautiful city of Japan. 

Send resume to: Dr. Masanobu Matsuo, 
29121 Firthridge, Rancho Palos Verdes, CA 
90274; (213) 544-0855. 


PROGRAMMER 
Structural Analyst 

Programmer, Structural Analyst—Min. 2 
years experience structural or civil engineer¬ 
ing and BS degree either field in addition to 
knowledge and ability to convert this knowl¬ 
edge into computer language for our firm 
which markets computer software for engi¬ 
neering firms relating to stress analysis of 
hydraulic tubing and pipeline designs. Must 
have experience relating to seismic response 
and failure analysis. California License not 
required. Salary $39800 year. Send resume 
to: Powell Morgan Inc., 19995 Sischo Drive, 
Topanga, CA 90290, Attn: Mr. Morgan. 


THE AMERICAN UNIVERSITY 
IN CAIRO 


One Assistant, Associate, or Full Professor 
needed to teach, in English, undergraduate 
courses in Computer Science including 
theory of computing and design of algo¬ 
rithms. Ph.D. required. Rank, salary based 
on qualifications and experience. Two-year 
appointment (renewable) beginning Sep¬ 
tember 1990. For expatriates, housing, 
roundtrip air travel, plus schooling for two 
children included. Write with curriculum 
vitae to: Dean George H. Gibson, The 
American University in Cairo, 866 United 
Nations Plaza, Suite 517, New York, New 
York 10017, preferably before December 



Jobs for 
computer 
pros! 

Every week, the National Business 
Employment Weekly, published by 
The Wall Street Journal, contains 
hundreds of high-paying jobs from all 
across the country, including career 
opportunities in virtually every area 
of computer technology. 

PLUS...weekly editorial features 
covering every aspect of career 
advancement. 

"Computer" Issue. 

October 1st. 

Extra career opportunities 
for computer professionals. 

Pick up the National Business 
Employment Weekly at your news¬ 
stand today. Or we'll send you the 
next eight issues by first class mail. 
Just send a check for $35 to: 

National 
Dept. 


Business Employment Weekly 
IC5, 420 Lexington Avenue 
New York, NY 10170 
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UNIVERSITY OF MIAMI 
Coral Gables, Florida 

The Department of Electrical and Com¬ 
puter Engineering invites applications for a 
tenure-track faculty position in Computer 
Science/Engineering at the Assistant/Asso¬ 
ciate Professor level. Preferred areas of in¬ 
languages, software engineering, and data¬ 
base. Qualifications include an earned doc¬ 
torate and potential for quality research and 
teaching. Salary will be commensurate with 
rank and experience. The University is 
located in Coral Gables, a suburb of Miami, 
FL. Applications should be sent with the 
names of three references to: Dr. Tzay Y. 
Young, Acting Chair, Department of Electri¬ 
cal and Computer Engineering, P.0. Box 
248294, University of Miami, Coral Gables, 
Florida 33124. The University of Miami is 
an equal opportunity/affirmative action 
employer. 


SOFTWARE DEVELOPER 

Full time position to work for software 
consulting firm located in Central Ohio, 
Monday through Friday, 7:45 a.m. to 4:45 
p.m. Duties involve design, development, 
enhancement, and maintenance of a man¬ 
agement maintenance and information sys¬ 
tem for telephone switching operation. 
Duties include: development of a high level 
of familiarization, understanding and analy¬ 
sis of SCCS and its subsystems; develop¬ 
ment of a high level of familiarization, under¬ 
standing, and analysis of the management 
and maintenance utility systems; design and 
development of enhancement features with 
special attention to interfacing with O/S 
kernel, hardware and system’s limitations 
and parameters; development and coding of 
program modules in C on UNIX; testing, 
modifications, and debugging of programs to 
insure compliance with intended system’s 
specifications; field testing of programs to be 
incorporated into subsystem’s modules and 
submodules including interfacing with other 
modules and subsystems; development and 
writing of software documentation; perform 
any other assignment not identified above as 
instructed by immediate supervisor. No ex¬ 
perience necessary. Must have an M S. in 
computer information science or an M.S. in 
engineering (Major field of study; electrical 
and computer engineering). Must have writ¬ 
ten 3000 lines of C on UNIX and taken a 
graduate level course in C and UNIX or must 
have completed a project (academic or work 
environment) written in C on UNIX (2500 
lines) which required three shell programs 
and two shell language utilities (sed, awk, 
grep) and two programming development 
tools (lint, cc, lex, yacc), and one debugging 
tool (sdb, dbx, or adb). Must also have 
ported a C or Gnu C compiler on UNIX and 
taken one advanced course at the graduate 
level in operating systems. Must also have 
taken one graduate-level course in data com¬ 
munications and networks. Salary $38,000/ 
yr. Send resume, (NO CALLS) to R. Lech- 
ler, JO # l 108844, Ohio Bureau of Employ¬ 
ment Services, P.O. Box 1618, Columbus, 
Ohio 43216. An equal opportunity employer. 


CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 864-8272; 
Compmail, e.gallizzi 


Fault tolerance apt to be vital feature of future 
computers, keynoter tells symposium 

Kewal K. Saluja, University of Wisconsin at Madison 
Sudhakar M. Reddy, University of Iowa at Iowa City 


Fault tolerance in computer systems 
is likely to be an important feature in 
the design of the high-performance 
computers of tomorrow. That was the 
key message Edward S. Davidson of the 
University of Michigan delivered when 
he keynoted the 19th International 
Symposium on Fault Tolerant Comput¬ 
ing in Chicago June 21-23. 

The conference, which covers all 
hardware and software aspects of fault- 
tolerant computing, was sponsored by 
the IEEE Computer Society. Ravi Iyer 
of the University of Illinois and Jacob 
Abraham of the University of Texas at 
Austin were the conference general co¬ 
chairs. Sudhakar Reddy of the Univer¬ 
sity of Iowa served as program chair. 

The proceedings, order No. 1959, is 
available from the Computer Society 
Press, Los Alamitos, California, by 
calling (800) CS-BOOKS or (714) 
821-8380 in California. 

Davidson indicated that fault toler¬ 
ance is no longer an esoteric research 
area limited to a few people in the aca¬ 
demic world or large research organiza¬ 
tions. He indicated that fault-tolerant 
techniques have come a long way since 
the days of special application systems 
and are being applied to commercial 
systems. 

Thus, he said, the relevance of this 
conference to the computer world has 
increased substantially. He indicated 
that much common ground exists 
between fault tolerance and computer 
architecture. The goals of fault-tolerant 
design and high-performance architec¬ 
ture have common ground since both 
need to address the problems of excep¬ 
tion detection, recovery, and security. 
By sharing resources (hardware and 
software) that are common and are used 
to solve these problems, the cost of 
dealing with these problems can be 
reduced. Both disciplines stand to gain. 

Special session. A unique feature of 
the conference was a special session 


composed of four invited presentations 
and papers by international industrial 
researchers. The speakers in this session 
presented the industrial perspective of 
fault tolerance, including how fault- 
tolerance concepts and techniques were 
being used and analyzed in their compa¬ 
nies. Three of the four papers described 
the application of fault tolerance in tele¬ 
phone systems. 

Ytzhak Levendel of AT&T Bell 
Laboratories discussed software issues 
in a paper entitled “Defects and Relia¬ 
bility Analysis of Large Software Sys¬ 
tems: Field Experience.” Takahiko 
Yamada and Satoshi Ogawa of NTT of 
Japan discussed hardware issues in their 
paper, “Fault-Tolerant Multiprocessor 
for Digital Switching Systems.” 

Michele Morganti of Italtel in Italy 
presented a paper entitled “F-T 
Telecommunications Networks: State, 
Perspectives, Trends” that provided an 
overall view of telecommunications 
networks. 

Levendel presented work that ana¬ 
lyzed and modeled the software devel¬ 
opment process based on field 
experience for large distributed systems. 
In particular, it was found that software 
defect removal was the bottleneck in 
achieving the appropriate system qual¬ 
ity level before deployment in the field. 

From field experience, it has been 
found that the average time between the 
delivery of software and fault detection 
was four months. Levendel stated that 
the length of time to find the defects 
“must have a sobering impact on our 
thinking.” 

The problem is amplified by the sur¬ 
prising rate of new defects introduced at 
defect-repair time. In modeling of the 
defect detection and repair rates, it was 
found that one defect is reintroduced 
for every three defects repaired. Addi¬ 
tionally, most of the defects found by 
the customers were defects reintroduced 
at repair time. 

“The defect introduction rate 


106 


COMPUTER 













dominates by far the process of improv¬ 
ing software quality,” Levendel said. 

He concluded by pointing out that the 
high software complexity of large dis¬ 
tributed systems “ ... leads to a pes¬ 
simistic outlook with respect to the 
industry’s ability to control down the 
residual latent defects in a large soft¬ 
ware product.” But this can be 
mitigated by the “partitioning of the 
product into smaller products,” he 
said. 

Failure magnitude dependence. 

Yamada and Ogawa presented the D70 
digital switching system’s fault-tolerant 
aspects, which are based on the failure 
magnitude dependence concept. This 
concept “stresses the effect of failure 
on society rather than equality of the 
individual service subscriber.” 

The fault recovery strategy is hierar¬ 
chical. In the first stage, local fault 
recovery is attempted within the local 
processor. If this is not possible, the 
next stage initiates global fault recovery 
by the master control processor (MCP), 
which is one of the multiple processors 
in the system. The next recovery stage is 
initiated completely in hardware via the 
multiprocessor emergency action circuit 
(MEMA), which is activated if the MCP 
is unable to reconstruct the system. 

The MEMA, a highly reliable circuit, 
chooses a new processor to become the 
MCP. The external supervisory equip¬ 
ment (ESE) acts as an “outside watch¬ 
dog” by periodically sending call 
signals to the system. If it gets no 
response, it initiates system recovery via 
the MEMA. 

From field reports, with about 900 


sites and a total operational time of 
more than one million processor hours, 
the system unavailability is less than 
10“ s . 

Morganti stated that “ ... [public 
telecommunication networks] have 
functional and physical characteristics 
that make them intrinsically able to sur¬ 
vive (and therefore, up to a certain 
degree, tolerate) a large number of fault 
situations.” These characteristics are 
the larger amount of resources neces¬ 
sary to support worst case load over the 
average load, the high level of connec¬ 
tivity of the networks, and extreme dis¬ 
tribution of the network intelligence. 

But, he went on to say, “More 
recently, the massive use of SPC (stored 
program control) and computers for all 
network functions seriously endangered 
these useful properties.” The intrinsic 
robustness has been eroded by the 
growing concentration of the network 
intelligence (versus the older elec¬ 
tromechanical switching technology), 
increase in the average exploitation of 
all statistically sized network elements 
through better load balancing tech¬ 
niques, reduced number of hierarchical 
levels, and increased number and eco¬ 
nomical convenience of network cen¬ 
tralized services. 

Concerning the relative levels of soft¬ 
ware and hardware fault tolerance, 
Morganti stated, “Opposite to their 
high level of hardware redundancy and 
fault tolerance, all existing switching 
systems also share a substantial lack of 
software fault tolerance. Yet, practical 
field experience clearly indicates that 
software exceeds hardware as a source 
of switching system failure both in aver¬ 


age frequency and in duration.” 

Fourth invited paper. Robert Horst 
of Tandem Computers described the 
design and related repair policy for the 
cache and control store static RAM 
memories in the Tandem NonStop VLX 
in the fourth invited paper, “Reliable 
Design of High-Speed Cache and Con¬ 
trol Store Memories.” 

Horst emphasized that incentive for 
improved RAM reliability was for ser¬ 
vice cost reduction because “in a fault- 
tolerant system, single failures are toler¬ 
ated by the system architecture, and the 
frequency of double failures is so low 
that improvements in component fail¬ 
ure rates have little measurable effect 
on overall system reliability.” 

The RAM design decision, which 
rejected Hamming ECC codes because 
of the high impact of performance, 
chose to use substitutable spare RAM. 

A cache read error is identified by a 
parity error and corrected by signaling a 
cache miss, which will refetch the block 
from main memory. 

The microcode counts the number of 
parity errors and, when a threshold is 
exceeded, the spare RAM is switched in 
place of the defective RAM. Since the 
cache uses a write-through policy, the 
particular defective RAM chip is identi¬ 
fied by comparing the word read from 
cache that contains the error with the 
corresponding correct word from main 
memory. The cache RAM integrated 
circuit organization includes 32 data 
RAMs, eight parity RAMs, and one 
spare RAM that can be substituted for 
any of the other 40. The total cache size 
is 64 kilobytes. 


Neural nets, optical technology key current research areas, keynoter asserts 

Behrooz Shirazi, Southern Methodist University 


Both the connectionist model based 
on neural networks and optical technol¬ 
ogy are at the forefront of computing 
research, said Kai Hwang of the Univer¬ 
sity of Southern California when he 
keynoted a May 22-23 Dallas confer¬ 
ence. He spoke at the First IEEE Sym¬ 
posium on Parallel and Distributed 
Processing. 

Behrooz Shirazi of Southern Method¬ 
ist University served as general chair of 
the symposium, and Mark Shadowens 
of Texas Instruments was the program 
chair. The Dallas Section of the IEEE 
Computer Society sponsored the event. 

Besides Hwang’s talk, the symposium 


featured two panel discussions, 16 tech¬ 
nical sessions, and two full-day tutorials 
May 24. 

The technical sessions dealt with par¬ 
allel and distributed systems covering 
networks, neural nets, algorithms, 
architectures, databases, artificial intel¬ 
ligence, languages, and operating 
systems. 

In one tutorial session, A.R. Hurson 
of Pennsylvania State University 
covered supercomputer architectures, 
while, in the other session, S. Brawer of 
Encore Computer discussed commercial 
and defense applications of parallel 
processors. 


Keynote remarks. In his presentation, 
Hwang discussed massively parallel 
computing with optics and connec¬ 
tionist neural network models. He 
predicted that the next generation of 
computers will be able to effectively 
simulate artificial neural nets using 3D 
wafer scale integration technology com¬ 
bined with optical interconnections. 

The connectionist model was defined 
based on the information processing 
properties of neurons. Each computing 
cell is a (nonlinear) thresholding device 
with internal state. The knowledge is 
stored as the connection strengths 
among the cells. The model has the 
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properties of concurrent, cooperative- 
competitive computations, self learn¬ 
ing/reorganization, fault-tolerance, and 
working with incomplete knowledge. 

Hwang briefly discussed two innova¬ 
tive architectures for parallel neural net 
simulations. The first architecture is 
based on modification of the hypercube 
to a communication-efficient hypernet 
with dense interconnects at lower 
dimensions and hierarchically sparser 
interconnects at higher dimensions. The 
second architecture is based on generali¬ 
zation of the orthogonal multiprocessor 
to k-ary and high dimensions for mas¬ 
sive parallelism. 

Hwang then predicted that massively 
parallel architectures for neural net 
simulations will become more a reality 
than fantasy, once optical interconnec¬ 
tion networks can be developed. He dis¬ 
cussed the properties of optical 
computing as having higher switching 
speeds, no planner constraints, reduced 
mutual interference, no pinout limita¬ 


tions, and no capacitive loading effects. 
For example, the switching speed of 
optical computers is on the order of 
10“ 12 to 10“ 15 seconds compared to 
10“ 9 to 10“ 11 in electronic computers. 

Similarly, the communication band¬ 
width of optical computers is on the 
order of 1 to 10 2 gigabits per second, 
while that of electronic computers is on 
the order of 10 to 10 3 megabits per 
second. 

Hwang concluded by proposing a 3D 
wafer scale integrated architecture with 
optical links among the wafers as a suit¬ 
able system for implementing the mas¬ 
sively parallel connectionist computa¬ 
tion model. 

Panel sessions. The first panel discus¬ 
sion dealt with creating a standard 
parallelizing Fortran compiler for paral¬ 
lel supercomputers. 

The panelists represented major 
supercomputer manufacturers and 
included Mark Furtney of Cray 


Hermes remote procedure call system described at 

Darrell Long, University of California at Santa Cruz 
Umakishore Ramachandran, Georgia Institute of Technology 


Andrew Black of Digital Equipment 
described the Hermes system during his 
paper presentation at the Ninth Interna¬ 
tional Conference on Distributed Com¬ 
puting Systems in Newport Beach, 
California, June 5-9. The system pro¬ 
vides a means for location-independent 
remote procedure call in a system com¬ 
posed of from thousands to tens of 
thousands of nodes. 

Kane Kim of the University of 
California at Irvine was the ICDCS 9 
general chair, and Norman Schneide- 
wind of the Naval Postgraduate School 
served as program chair. William Wulf 
of the National Science Foundation was 
the keynote speaker. 

ICDCS is the primary conference 
series sponsored by the IEEE Computer 
Society and its Technical Committee on 
Distributed Processing. All told, the 
conference featured 24 sessions, with 
topics covering distributed operating 
system issues, databases, communica¬ 
tions, and fault tolerance. Two panel 
sessions were conducted, one dedicated 
to distributed system design tools and 
the other to distributed virtual memory. 

As with all computing disciplines, 
distributed computing has undergone 
great change during the past decade. 
Distributed computing has matured 
and, in many cases, become the norm. 


It is now common to find networks of 
workstations all sharing a common 
name-space through a file server. Dis¬ 
tributed services, such as dictionaries 
and time and weather reports, are 
becoming available. 

The ICDCS 9 proceedings, order No. 
1953, is available from the Computer 
Society Press, Los Alamitos, Califor¬ 
nia, by calling (800) CS-BOOKS or 
(714) 821-8380 in California. 

Hermes presentation. In his talk on 
the Hermes system, Black said a pri¬ 
mary goal of remote procedure call 
(RPC) is to make remote invocation as 
similar to the well-understood local 
procedure call as possible. An impor¬ 
tant part of this is relieving the pro¬ 
grammer of worry about which remote 
address space the procedure will execute 
in. This is complicated by a large name 
space where objects (for performance 
or fault-tolerance reasons) may be 
mobile. 

Locating an object in a large and fre¬ 
quently changing system can be diffi¬ 
cult. Maintaining an accurate mapping 
of objects to locations is a significant 
database problem. Replication is often 
used, and name servers often trade con¬ 
sistency for availability. Location- 
independent invocation (LII) relieves 


Research, Lesly Toomey of IBM, Bob 
Kuhn of Alliant Computer Systems, 
and Bob Metzger of Convex Com¬ 
puters. They discussed the need for a 
standardized and transportable lan¬ 
guage to support parallel supercom¬ 
puters as well as current efforts to 
generate a standard. 

In the second panel discussion, on the 
Superconducting Super Collider, 
panelists alluded to the extensive com¬ 
putational needs of the project, includ¬ 
ing both design and operation. The 
need for extremely powerful parallel 
systems just to design the Super Col¬ 
lider are no less important than the on¬ 
line needs of the operating machine, it 
was stated. 

The use of a microprocessor farm to 
support real-time data collection from 
experiments performed and the need for 
data reduction underscored the degree 
to which the Super Collider project will 
utilize parallelism. 


ICDCS 9 


the programmer of this burden. 

The Hermes system attempts to auto¬ 
mate the expense voucher system DEC 
uses. A voucher is completed by an 
employee and must be signed by several 
managers before the employee can be 
paid. The vouchers are mobile objects 
that move as required between nodes, 
such as employee and manager worksta¬ 
tions. This is done for the sake of inter¬ 
active response, since the Digital 
network contains some 30,000 nodes 
and is geographically dispersed. 

Each object has a unique permanent 
global identifier and maintains the 
name of the Hermes node that contains 
the volatile copy of the object as well as 
an age. The age of the object is the 
number of times the object has moved 
to a new location. Each Hermes node 
keeps a cache of object locations, 
including local objects and those remote 
objects that have been recently 
referenced. 

The location algorithm first attempts 
to invoke the object on the local node 
and, if that fails, goes on to use increas¬ 
ingly reliable (and expensive) methods 
for locating the object. The algorithm 
will then use the cache of object loca¬ 
tions to locate the object. These are 
used as forwarding addresses and can 
cause the algorithm to check the caches 
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at remote nodes. If this fails, a storage 
site for the object is found using the 
name service, and that node is consulted 
to determine the location of the object. 
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Distributed virtual memory panel. 

Umakishore Ramachandran of the 
Georgia Institute of Technology chaired 
the distributed virtual memory panel 
session, which focused on this abstrac¬ 
tion for structuring distributed systems. 
The panel included Black; Luis-Felipe 
Cabrera, IBM Almaden Research; 

David Jefferson, the University of 
California at Los Angeles; and Larry 
Wittie, the State University of New 
York at Stony Brook. 

Wittie described architectural 
developments in multiprocessors to sup¬ 
port global virtual memory spanning 
thousands of processors. In particular, 
he talked about the IEEE PI596 stan¬ 
dard for scalable coherent interfaces, 
the scalable cache project at Stanford 
University, and a system for global vir¬ 
tual memory over a network of heter¬ 
ogeneous machines being developed at 
Stony Brook. 

Black pointed out that the geographi¬ 
cal span of distributed computing 
ranges from a single chip to the uni¬ 
verse. The mechanism that is appropri¬ 
ate for a LAN, for example, may not be 
applicable for a system that spans the 
entire world. While conceding that dis¬ 
tributed virtual memory is here to stay, 
he noted that the level at which it exists, 
the granularity of sharing, and the 
extent of transparency depend on the 
geographic size of distribution. 

Jefferson contrasted distributed vir¬ 
tual memory to message passing and 
espoused the benefits of the former over 
the latter. In particular, he pointed out 
that distributed virtual memory allows 
all aspects of a distributed system to be 
built using a single abstraction. A 
message-based system, for example, 
must perform such bookkeeping chores 
as routing tables, messages in transit, 
and flow control to allow process 
migration while, in a distributed virtual 
memory system, the only bookkeeping 
necessary to effect process migration is 
locating the virtual pages. 

Cabrera claimed that distributed vir¬ 
tual memory will not work in a globally 
distributed network. He cautioned that 
any abstraction is good only if it is good 
to use, and an implementation of an 
abstraction is only good if it applies to 
all understood target architectures. His 
main concern was that latency will 
make the distributed virtual memory 
abstraction unusable in a global net¬ 
work. He claimed that it can and will 
only be usable as an application-specific 
layer. 


The accompanying Calendar section is now printed with a blue background 
to make it easier to find. In addition, the Calendar has been extended to include 
a full year of listings. The IEEE Computer Society logo indicates the conferences the 
society is sponsoring and participating in; additional conference sponsors are also 
listed. Other conferences of interest to our readers are included, as well. 

For inclusion in Call for Papers or Calendar, submit information six weeks before 
the month of publication (i.e., for the November 1989 issue, send information for 
receipt by September 15, 1989) to Chuck Governale, Calendar Dept., Computer, 
PO Box 3014, Los Alamitos, CA 90720. 
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^2^, Canadian Conf. on Electrical and 
Computer Engineering, Sept. 17-20, 

Montreal. Sponsor: Canadian Society of Elec¬ 
trical Engineering. Contact Micha Avni, 
CCECE 89, PO Box 577, Desjardins Postal Sta¬ 
tion, Montreal, Que., Canada, H5B 1B7, phone 
(514) 283-0004; or Paul E. Allard, Transporta¬ 
tion Development Center — Transport Can¬ 
ada, 200 Rene-Levesque Blvd. West, Suite 
601, West Tower, Montreal, Que., Canada, 
phone (514) 283-0004. 

Workshop on Unix System Administration, 
Sept. 18-19, Somerset, N.J. Contact Thomas 
V. Pottanat, NYNEX, 500 Westchester Ave., 
2D-4, White Plains, NY 10604, phone (914) 
683-2186; or Thomas M. Raleigh, Bell Com¬ 
munications Research, 445 South St., MRE 
2A-343, Morristown, NJ 07960-1910, phone 
(201) 829-4321. 

HCI Int’l 89, Third Int’l Conf. on Human- 
Computer Interaction, Sept. 18-22, Boston. 
Cosponsors: IEEE Systems, Man, and Cyber¬ 
netics Society et al. Contact Michael J. Smith, 
Industrial Engineering Dept., Univ. of Wis¬ 
consin, 1513 University Ave., Madison, WI 
53706, phone (608) 263-6329. 

Network Management and Control Work¬ 
shop, Sept. 19-21, Tarrytown, N.Y. Sponsors: 
IEEE et al. Contact Ivan Frisch, Center for Ad¬ 
vanced Technology in Telecommunications, 
Polytechnic Univ., 333 Jay St., Brooklyn, NY 
11201, phone (718) 260-3050. 

10th Systems Science Int’l Conf., Sept. 19- 
22, Wroclaw, Poland. Contact Jerzy Swiatek, 
Technical Univ. of Wroclaw, Inst, of Control 
and Systems Engineering, Janiszewski St. 11/ 
17, 50-370 Wroclaw, Poland. 


N Compsac 89, 13th Int’l Computer 
Software and Applications Conf., 
Sept. 20-22, Kissimmee, Fla. Contact IEEE 


Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013; or Stephen S. Yau, CIS Dept., 
801 CSE, Univ. of Florida, Gainsville, FL 
32611, phone (904) 335-8006. 

Fifth Int’l Conf. on Image Analysis and Pro¬ 
cessing, Sept. 20-22, Positano, Italy. Spon¬ 
sors: Int’l Assoc, for Pattern Recognition et al. 
Contact Gabriella Sanniti di Baja, c/o Istituto 
di Cibemetica, C.N.R., 1-80072 Arco Felice, 
Naples, Italy, phone 39 (81) 867-1255. 


Int’l Electronics Manufacturing Technol¬ 
ogy Symp., Sept. 25-27, San Francisco. Spon¬ 
sor: IEEE Computer Society Components, 
Hybrids, and Manufacturing Technology So¬ 
ciety. Contact Diana Bendz, IBM Corp., Dept. 
363/033-3, 1701 North St., Endicott, NY 
13760, phone (607) 755-3521. 


^2^. ASIC 89, Application-Specific Inte- 
grated Circuit Seminar, Sept. 25-28, 

Rochester, N.Y. Contact Lynne M. Engel- 
brecht, 170 Mt. Read Blvd., Rochester, NY 
14611, phone (716) 328-2310; or Jon K. Ed¬ 
wards, Eastman Kodak, Dept. 434, FI. 1, Bldg. 
9, Rochester, NY 14650, phone (716) 726-9222. 


Sept. 25-29, Milan, Italy. Sponsor: 

ACM. Contact Luc Steels, Free Univ. 
Brusselles, Al Lab, Pleinlaan 2, Gebouw K2B- 
1050, Brussels, Belgium. 


Third Int’l Workshop on Distributed Algo¬ 
rithms, Sept. 26-28, Nice, France. Contact 
Jean-Claude Bermond, LRI, Bat 490, Univer- 
site Paris-Sud, 91405 Orsay, France. 


£2^ Performance Evaluation, Reliability, 
and Exploitation of Computer Sys¬ 
tems, Sept. 26-29, Walbrzych, Poland. Spon¬ 
sors: Polish Informatic Society et al. Contact 
George J. Anders, Stations and Underground 
Section, Electrical Research Dept., Ontario 
Hydro, 800 Kipling Ave., KR 151, Toronto, 
Ont., Canada M8Z 5S4, phone (416) 231-4111. 
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ZS^, Second IEEE Workshop on Worksta- 
*557 tion Operating Systems, Sept. 27-28, 

Pacific Grove, Calif. Contact Joseph Boykin, 
Encore Computer, 257 Cedar Hill St., Marlbor¬ 
ough, MA 01752, phone (508) 460-0500. 


27th Allerton Conf. on Communication, 
Control, and Computing, Sept. 27-29, Mon- 
ticello, Ill. Sponsor: Univ. of Illinois at Ur- 
bana-Champaign. Contact J.V. Medanic or 
P.R. Kumar, Allerton Conf., Coordinated Sci¬ 
ence Lab, Univ. of Illinois, 1101 W. Spring- 
field Ave., Urbana, IL 61801-3082. 


October 1989 


Fourth Knowledge Acquisition for Knowl¬ 
edge-Based Systems Workshop, Oct. 1-6, 

Banff, Canada. Sponsor: American Assoc, for 
Artificial Intelligence. Contact John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, Seattle, 
WA 98124, phone (206) 865-3253. 


ZZJ> Protext V, Fifth Int’l Conf. on Com- 
*5*7 puter-Aided Text Processing and Its 
Applications, Oct. 4-6, Cambridge, Mass. 
Sponsor: Inst, for Numerical Computation and 
Analysis. Contact John Miller, INCA, PO Box 
2, Dun Laoghaire, County Dublin, Ireland, 
phone 353 (1) 772-941. 


Workshop on Experiences with Build- 
*5|7 ing Distributed and Multiprocessor 
Systems, Oct. 5-6, Fort Lauderdale, Fla.. 
Sponsor: Usenix. Contact George W. Leach, 
PO Box 2826, MS LG-129, Largo, FL 34649- 
2826, phone (813) 530-2376. 


Eighth Symp. on Reliable Distributed 
*5l7 Systems, Oct. 10-12, Seattle. Contact 
Jane W.S. Liu, Computer Science Dept., Univ. 
of Illinois, 1101 W. Springfield Ave., Urbana, 
IL 61801-3082, phone (217) 333-6769 or 0135. 

Z2^, 14th Conf. on Local Computer Net- 
*5*7 works, Oct. 10-12, Minneapolis. Con¬ 
tact Ron Rutledge, Martin Marietta Energy 
Systems, Oak Ridge Nat’l Lab, Bldg. 4500N, 
MS 6271, PO Box 2008, Oak Ridge, TN 37831- 
6271, phone (615) 576-7643. 


puter Science Dept., Univ. of Toronto, Stan¬ 
ford Fleming Bldg., 10 King’s College Circle, 
Toronto, Ont. M5S 1A4, Canada, phone (416) 
978-7441. 


Int’l Workshop on Defect and Fault 
’54J’ Tolerance in VLSI Systems, Oct. 23- 
24, Tampa, Fla. Contact D.L. Landis, Electri¬ 
cal Engineering Dept., Univ. of South Florida, 
Tampa, FL 33620, or Charles H. Stapper, Dept. 
A23, Bldg. 861-1, IBM, Essex Junction, VT 
05452, phone (802) 769-6655. 

^2^1 IEEE Computer Society Workshop on 
’5*7 Tools for Artificial Intelligence, Oct. 
23-25, Fairfax, Va. Contact Nikolas G. Bour- 
bakis, Machine Vision Research Lab, ECE 
Dept., SITE, George Mason Univ., 4400 Uni¬ 
versity Dr., Fairfax, VA 22030, phone (703) 
425-3930. 


1989 Beijing Int’l Conf. on System Simula¬ 
tion and Scientific Computing, Oct. 23-26, 

Beijing, China. Sponsors: Society for Com¬ 
puter Simulation et al. Contact Wen Chuan- 
Yuan, Beijing Inst, of Aeronautics and Astro¬ 
nautics, Beijing, China. 


ICCD 89, IEEE Int’l Conf. on Computer De¬ 
sign, Oct. 2-4, Cambridge, Mass. Cosponsor: 
IEEE Circuits and Systems Society. Contact 
Sumit Das Gupta, IBM, Bldg. 306, ZIP 3A1, 
Hopewell Junction, NY 12533, phone (914) 
894-0540; or Giovanni DeMicheli, Stanford 
Univ., Center for Integrated Systems, Rm. 129, 
Stanford, CA 94305, phone (415) 725-3632. 

CAPE 89, Computer Applications in Pro¬ 
duction Engineering Conf., Oct. 2-5, Tokyo. 
Sponsors: IFIP, IPSJ, JSPE. Contact Business 
Center for Academic Societies of Japan, 2-40- 
14, Hongo, Bunkyo-ku, Tokyo 113, Japan, 
phone 81 (3) 817-5831. 

OOPSLA 89, Fourth Conf. on Object-Ori¬ 
ented Programming Systems, Languages, 
and Applications, Oct. 2-6, New Orleans. 
Sponsor: ACM. Contact OOPSLA 89, c/o Jeff 
McKenna, McKenna Consulting Group, 8825 
SW Umatilla St., Tualatin, OR 97062. 

/£j^l Second Int’l Workshop on Software 
’517 Configuration Management, Oct. 3-6, 

Princeton, N.J. Cosponsors: ACM, Gesellschaft 
fiir Informatik. Contact Thomas Murphy, 
Siemens Research, 755 College Rd. E, Prince¬ 
ton, NJ 08540, phone (609) 734-6560. 

1989 IEEE Ultrasonics Symp., Oct. 3-6, 
Montreal. Sponsor: IEEE Ultrasonics, Ferro- 
electrics, and Frequency Control Society. 
Contact Herman van de Vaart, Allied-Signal, 
Box 1021R, Morristown, NJ 07960, phone 
(201) 455-2482; or Narendra K. Batra, Code 
6385, Naval Research Lab, Washington, DC, 
20375-5000, phone (202) 767-3505. 

ITU-COM 89, First World Electronic 
*^7 Media Symp., Oct. 3-8, Palexpo, Ge¬ 
neva, Switzerland. Contact ITU-COM 89 Sec¬ 
retariat, Int’l Telecommunication Union, 

Place des Nations, CH-1211 Geneve 20, Swit¬ 
zerland, phone 41 (22) 99-5190. 


Fifth Int’l Software Process Work- 
^§7 shop, Oct. 10-13, Kennebunkport, Maine. 
Sponsor: Rocky Mountain Inst, of Software 
Engineering. Contact Dewayne Perry, AT&T 
Bell Labs, Rm. 3D-454, 600 Mountain Ave., 
Murray Hill, NJ 07974, phone (201) 582-2529. 

Int’l Symp. on Computer Architecture and 
Digital Signal Processing, Oct. 11-14, Hong 
Kong. Sponsor: IEEE. Contact Wan-Chi Siu, 
Electronic Engineering Dept., Hong Kong 
Polytechnic, Hung Horn, Kowloon, Hong 
Kong, phone (852) 3-638344, ext. 496. 

Fourth Int’l High-Level Synthesis 
*5*7 Workshop, Oct. 15-19, Kennebunk¬ 
port, Maine. Cosponsor: ACM. Contact Gae¬ 
tano Borriello, Computer Science Dept., FR 
35, Univ. of Washington, Seattle, WA 98195, 
phone (206) 543-1695. 

.£2^1 Data and Knowledge Systems for 
*5*7 Manufacturing and Engineering, Oct. 
16-18, Gaithersburg, Md. Cosponsor: ACM. 
Contact Lawrence A. Rowe, Computer Sci¬ 
ence Div.—EECS, Univ. of California, 
Berkeley, CA 94720, phone (415) 642-5117. 

CSM 89, Conf. on Software Mainte- 
N§7 nance, Oct. 16-19, Miami, Fla. Contact 
CSM 89, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013; or Wilma 
Osborne, NIST, Bldg. 225, Rm. B266, Gaith¬ 
ersburg, MD 20899, phone (301) 975-3339. 

First Int’l Conf. on Artificial Neural Net¬ 
works, Oct. 17-18, London. Sponsor: Institu¬ 
tion of Electrical Engineers. Contact Conf. 
Services, IEE, Savoy PI., London WC2R 0BL, 
UK, phone 44 (1) 24-01-871. 

Eighth Int’l Conf. on Entity-Relationship 
Approach, Oct. 18-20, Toronto. Sponsor: ER 
Inst. Contact Frederick H. Lochovsky, Corn- 


Second Int’l Symp. on Artificial Intelligence, 
Oct. 23-27, Monterrey, Mexico. Contact Fran¬ 
cisco J. Cantu, Inst. Tecnologico de Monter¬ 
rey, ITESM Sue. Correos “J,” Monterrey, 

N.L., Mexico 64849, phone 52 (83) 58-20-00. 

ZS^, 23rd Asilomar Conf. on Signals, Sys- 
*5*7 terns, and Computers, Oct. 30-Nov. 1, 

Pacific Grove, Calif. Cosponsors: Naval Post¬ 
graduate School, San Jose State Univ. Contact 
John T. Rickard, Orincon Corp., 9363 Towne 
Centre Dr., San Diego, CA 92121, phone (619) 
455-5530. 

jZI^i Third IFAC Workshop on Experience 
*5*7 with the Management of Software 
Projects, Oct. 30-Nov. 1, West Lafayette, Ind. 
Sponsor: Purdue Univ. Contact Frederic J. 
Mowle, School of Electrical Engineering, Pur¬ 
due Univ., West Lafayette, IN 47907, phone 
(317) 494-3440. 

^2^ FOCS 89, 30th Foundations of Com- 
'5*7 puter Science Conf., Oct. 30-Nov. 1, 
Research Park, N.C. Contact Christos Papa- 
dimitriou. Computer Science Dept., Univ. of 
California at San Diego, La Jolla, CA 92093, 
phone (619) 534-2086. 

ISCIS 4, Fourth Int’l Symp. on Computer 
and Information Sciences, Oct. 30-Nov. 1, 

Cesme, Turkey. Contact Asuman Dogac, Com¬ 
puter Engineering Dept., Middle East Techni¬ 
cal Univ., 06531 Ankara, Turkey. 

CIPS Edmonton 89, Oct. 30-Nov. 1, Edmon¬ 
ton, Alta., Canada. Sponsor: Canadian Infor¬ 
mation Processing Society. Contact Wayne A. 
Davis, Computing Science Dept., Univ. of Al¬ 
berta, Edmonton, Alta., Canada T6G 2H1, 
phone (403) 492-3976. 

ZZN FedCASE 89, Federal CASE Conf., 
'5*7 Oct. 30-Nov. 2, Gaithersburg, Md. 
Sponsor: Nat’l Inst, of Standards and Technol- 
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ogy. Contact Margaret H. Law or Wilma M. 
Osborne, NIST, Technology Bldg., Gaithers¬ 
burg, MD 20899, or 2107 Vermont Ave., Lan- 
dover, MD 20785. 


November 1989 


Ninth Symp. on Small Computers in 
the Arts, Nov. 3-5, Philadelphia, Pa. 
Sponsor: Small Computers in the Arts Network. 
Contact Dick Moberg, PO Box 1954, Philadel¬ 
phia, PA 19105, phone (215) 923-3299. 

Fifth Knowledge Acquisition for Knowl¬ 
edge-Based Systems Workshop, Nov. 4-9, 

Banff, Canada. Sponsor: American Assoc, for 
Artificial Intelligence. Contact John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, Seattle, 
WA 98124, phone (206) 865-3253. 

£SN. ICCAD 89, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 6-9, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact Andrezej J. 

Strojwas, ECE Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 268- 
3530; or IEEE Computer Society, 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 


GOMAC 89, Government Microcircuit Ap¬ 
plications Conf., Nov. 7-9, Orlando, Fla. 
Sponsors: US Dept, of Energy et al. Contact 
Randolph A. Reitmeyer, Electronics Technol¬ 
ogy and Devices Lab., Attn.: SLCET-I, Ft. 
Monmouth, NJ 07703-5000, phone (201) 544- 
3465. 

Fifth Int’l Congress on Advances in Non¬ 
impact Printing Technologies, Nov. 12-17, 

San Diego, Calif. Sponsor: Society for Imag¬ 
ing Science and Technology. Contact Wayne 
Jaeger, Tektronix, PO Box 500, MS 50-321, 
Beaverton, OR 97077, phone (503) 627-6714. 


Prociem 89, Second Conf. on Productivity 
through Computer Integrated Engineering 
and Manufacturing, Nov. 13-15, Orlando, 
Fla. Sponsor: Florida High Technology and 
Industry Council. Contact Vince Amico, Univ. 
of Central Florida, College of Extended Stud¬ 
ies, PO Box 25000, Orlando, FL 32816, phone 
(407) 275-2123. 

IFIP Int’l Workshop on Applied Formal 
Methods for Correct VLSI Design, Nov. 13- 
16, Leuven, Belgium. Cosponsors: IFIP, Inter¬ 
university Micro Electronics Center. Contact 
Luc Claesen, IMEC vzw, Kapeldreef 75, B- 
3030 Leuven, Belgium phone 32 (16) 281-203. 


Supercomputing 89, Nov. 13-17, Reno, 
^5? Nev. Cosponsor: ACM. Contact F. Ron 
Bailey, MS 258-5, NASA Ames Research 
Center, Moffett Field, CA 94035, phone (415) 
694-4500. 


Semiconductor Manufacturing Conf., Nov. 
14-15, Phoenix. Sponsor: Society of Manufac¬ 


turing Engineers. Contact Karen L. Kammerer, 
Technical Committee Projects Dept., SME, 1 
SME Dr., PO Box 930, Dearborn, MI 48121, 
phone (313) 271-1500. 

12th Western Educational Computing 
Conf., Nov. 16-17, Burlingame, Calif. Spon¬ 
sor: California Educational Computing Con¬ 
sortium. Contact Judah Rosenwald, Extended 
Education, NAD 153, San Francisco State 
Univ., 1600 Holloway, San Francisco, CA 
94132, phone (415) 338-1212. 

AIDA 89, Fifth Conf. on Artificial Intelli¬ 
gence and Ada, Nov. 16-17, Fairfax, Va. Co¬ 
sponsors: George Mason Univ., Inst, for De¬ 
fense Analyses, Software Productivity Con¬ 
sortium. Contact AIDA 89, Computer Science 
Dept., George Mason Univ., 4400 University 
Dr., Fairfax, VA 22030, phone (703) 323- 
2713. 

Tencon 89, IEEE Region 10 Conf., Nov. 22- 
24, Bombay, India. Sponsor: IEEE Bombay 
Section. Contact Kirit J. Sheth, Hakotronics 
Pvt. Ltd., Victoria Gardens, Bombay 400 027, 
India, phone 91 (22) 872-2888. 

IEEE Workshop on Interpretation of 
3D Scenes, Nov. 27-29, Austin, Texas. 
Contact Anil K. Jain, Computer Science Dept., 
Michigan State Univ., A-714 Wells Hall, East 
Lansing, MI 48824, phone (517) 353-5150. 


December 1989 


WSC 89, Winter Simulation Conf., 
Dec. 3-6, Washington, DC. Cosponsors: 
Society for Computer Simulation et al. Contact 
Sallie Sheppard, Office of Associate Provost, 
103 Academic Bldg., Texas A&M Univ., Col¬ 
lege Station, TX 77843, phone (409) 845- 
3210; or Philip Heidelberger, IBM Research 
Div., T.J. Watson Research Center, Haw¬ 
thorne, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7156. 

First Int’l Conf. on Deductive and 
Object-Oriented Databases, Dec. 4-6, 

Kyoto, Japan. Sponsor: Information Pro¬ 
cessing Society of Japan. Contact Won Kim, 
MCC, 3500 W. Balcones Center Dr., Austin, 
TX 78759, phone (512) 338-3439; Jean-Marie 
Nicholas, ECRC Arabellastr. 17, 8000 Munich 
81, FRG, phone 49 (89) 926-99-110; or Shojiro 
Nishio, Information and Computer Sciences 
Dept., Faculty of Engineering Sciences, Osaka 
Univ., Toyonaka, Osaka, 560 Japan, phone 81 
(6) 853-5737. 

Fifth Aerospace Computer Security 
Applications Conf., Dec. 4-8, Tucson, 
Ariz. Cosponsors: American Society for Infor¬ 
mation Science, ACSA. Contact Marshall 
Abrams, Mitre Corp., 7525 Colshire Dr., 
McLean, VA 22102, phone (703) 883-6938. 


10th Real-Time Systems Symp., Dec. 
'5*?' 5-7, Santa Monica, Calif. Contact Al 
Mok, Computer Science Dept., TAY 3-140C, 


Univ. of Texas, Austin, TX 78712, phone (512) 
471-9542. 


SIGSoft 89, Third Testing, Analysis, 
'^§7 and Verification Symp., Dec. 6-8, Key 

West, Fla. Cosponsor: ACM. Contact Richard 
A. DeMillo, Purdue Univ., Computer Science 
Dept., West Lafayette, IN 47907, phone (317) 
494-7823. 


Third Int’l Workshop on Petri Nets 
and Performance Models, Dec. 11-13, 

Kyoto, Japan. Cosponsors: Society of Instru¬ 
ment and Control Engineers et al. Contact 
Shojiro Nishio, Information and Computer 
Sciences Dept., Faculty of Engineering Sci¬ 
ences, Osaka Univ., Toyonaka, Osaka, 560 
Japan, phone 81 (6) 853-5737. 


Fourth SIAM Conf. on Parallel Processing 
for Scientific Computing, Dec. 11-13, Chi¬ 
cago. Sponsor: Society for Industrial and Ap¬ 
plied Mathematics. Contact SIAM Conf. Coor¬ 
dinator, 117 S. 17th St., 14th Floor, Philadel¬ 
phia, PA 19103-5052, phone (215) 564-2929. 

KBCS 89, Conf. on Knowledge-Based Com¬ 
puter Systems: Dec. 11-13, Bombay. Spon¬ 
sor: Government of India Dept, of Electronics. 
Contact S. Ramani, KBCS 89, National Centre 
for Software Technology, Gulmohar Cross Rd. 
No. 9, Juhu, Bombay 400 049, India. 

Int’l Conf. on CAD/CAM and Ad- 
'yp' vanced Manufacturing Technology in 
Israel, Dec. 19-21, Jerusalem, Israel. Cospon¬ 
sors: Israel Society for CAD/CAM, SME. Con¬ 
tact Lawrence R. Odess, Ortra, PO Box 50432, 
61500 Tel Aviv, Israel, phone 972 (3) 971- 
3991 or 664-825. 


Ninth Conf. on Foundations of Software 
Technology and Theoretical Computer Sci¬ 
ence, Dec. 19-21, Bangalore, India. Contact 
C.E. Veni Madhavan, Tata Research Develop¬ 
ment and Design Center, 1 Mangaldas Rd., 
Pune 411001, India, phone (212) 662-453. 

Sixth Israeli Conf. on Artificial Intelligence 
and Computer Vision, Dec. 26-27, Tel Aviv. 
Sponsor: Information Processing Assoc, of Is¬ 
rael. Contact IPA, PO Box 13009, 91130 
Jerusalem, Israel. 


January 1990 


HICSS 23, 23rd Hawaii Int’l Conf. on 
System Sciences, Jan. 3-5, Kailua 
Kona, Hawaii. Sponsor: Univ. of Hawaii. Con¬ 
tact Luqi, Computer Science Dept., Naval 
Postgraduate School, Monterey, CA 93943, 
phone (408) 646-2735. 


First Int’l Symp. on Artificial Intelligence 
and Mathematics, Jan. 3-5, Fort Lauderdale, 
Fla. Contact Frederick Hoffman, Mathematics 
Dept., Florida Atlantic Univ., PO Box 3091, 
Boca Raton, FL 33431-0991, phone (407) 
367-3340. 


September 1989 
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Winter 1990 Usenix Tech. Conf., Jan. 22-26, March 1990 

Washington, DC. Contact Daniel V. Klein, 

Software Engineering Inst., Carnegie Mellon 
Univ., Pittsburgh, PA 15213-3890, phone 
(412) 268-7791. 


April 1990 


Second IEEE Int’l Conf. on Wafer 
Scale Integration, Jan. 23-25, San 

Francisco. Contact Joe Brewer, 351 White Ce¬ 
dar Ln., Sevema Park, MD 21146, phone (301) 
765-1247. 


Ninth Int’l Conf. on Computing Meth- 
Wff ods In Applied Sciences and Engineer¬ 
ing, Jan. 29-Feb. 2, Paris. Cosponsor: INRIA. 
Contact INRIA, Service des Relations Exter- 
ieures, Domaine de Coloques — BP 105, 
78153, Rocquencourt, France; phone 33 (1) 
39-63-5600. 


February 1990 


Sixth Int’l Conf. on Data Engineering, 
Feb. 5-9, Los Angeles. Contact Joseph E. 
Urban, Arizona State Univ., College of Engi¬ 
neering and Applied Sciences, Computer Sci¬ 
ence Dept., Tempe, AZ 85287, phone (602) 
965-2774; or Sixth Int’l Conf. of Data Engi¬ 
neering, IEEE Computer Society, 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

Applications Technology Conf., Feb. 12-15, 

San Jose, Calif. Sponsor: American Electron¬ 
ics Assoc. Contact Ed Teja, American Elec¬ 
tronics Assoc., 5201 Great American Pkwy., 
Santa Clara, CA 95054, phone (503) 231-9914. 

Eurasip Workshop on Neural Networks, 
Feb. 15-17, Sesimbra, Portugal. Cosponsors: 
European Assoc, for Signal Processing, IEEE, 
Instituto de Engenharia de Sistemas e Compu- 
tadores. Contact Luis B. Almeida, INESC, 
Apartado 10105, P-1017 Lisboa Codex, Portu¬ 
gal, phone 351 (1) 544-607. 

CSC 90, 18th Computer Science Conf., Feb. 
20-22, Washington, DC. Sponsor: ACM. Con¬ 
tact Barbara Kyriakakis, Computer Science 
Dept., George Mason Univ., Fairfax, VA 
22030, phone (703) 323-2318. 

IEEE Computer Society Compcon 
Spring 90, Feb. 26-Mar. 2, San Fran¬ 
cisco. Contact Kenichi Miura, Computational 
Research Dept., MS B2-7, Fujitsu America, 
3055 Orchard Dr., San Jose, CA 95134-2017, 
phone (408) 432-1300, ext. 5408 or 5723; or 
Compcon Spring 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

Third Int’l Software for Strategic Sys- 
^ terns Conf., Feb. 27-28, Huntsville, Ala. 
Cosponsors: IEEE Computer Society 
Huntsville Chapter et al. Contact Continuing 
Education Div., Univ. of Alabama in 
Huntsville, Tom Bevill Center 285, 

Huntsville, AL 35899, phone (800) 448-4035 
or (205) 895-6372. 


Eighth Nat’l Conf. on Ada Technology, Mar. 
5-8, Atlanta. Contact Eighth Nat’l Conf. of Ada 
Technology, US Army Communications — 
Electronics Command, Attn.: AMSEL-RD- 
SE-CRM (Kay Trezza), Fort Monmouth, NY 
07703-5000. 

CAIA 90, Sixth IEEE Conf. on Artifi- 
cial Intelligence Applications, Mar. 5- 

9, Santa Barbara, Calif. Contact CAIA 90, 

IEEE Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013; or Se June Hong, IBM 
T.J. Watson Research Center, Rm. 31-206, PO 
Box 218, Yorktown Heights, NY 10598, phone 
(914) 945-2265. 

Parbase 90, Int’l Conf. on Databases, Paral¬ 
lel Architectures, and their Applications, 
Mar. 6-9, Miami Beach. Sponsors: Florida 
Int’l Univ. et al. Contact Parbase 90, School of 
Computer Science, Florida Int’l Univ., Miami, 
FL 33199, phone (305) 554-3429 or 3386. 

(£2^, EDAC 90, European Design Automa- 
'sU' tion Conf., Mar. 12-15, Glasgow, Scot¬ 
land. Contact Gordon Adshead, 1CL, 26 Al¬ 
bany St., Edinburgh, EH1 3QH, UK, phone 44 
(31) 557-2478. 

IEEE Computer Society 1990 Int’l 
Conf. on Computer Languages, Mar. 
12-16, New Orleans. Contact Boumediene 
Belkhouche, Computer Science Dept., Tulane 
Univ., PO Box 5079, 301 Stanley Thomas Hall, 
New Orleans, LA 70118, phone (504) 865- 
5840. 

1990 Symp. on Interactive 3D Graphics, 
Mar. 18-21, Snowbird, Utah. Sponsors: US 
Office of Naval Research et al. Contact Rich 
Riesenfeld, Univ. of Utah, Computer Science 
Dept., 3190 Merrill Engineering Bldg., Salt 
Lake City, Utah 84112, phone (801) 581-8224. 

IPCCC, Ninth IEEE Int’l Phoenix Conf. 
on Computers and Communications, Mar. 
21-23, Scottsdale, Ariz. Cosponsor: IEEE 
Communications Society. Contact Forouzan 
Golshani, Computer Science Dept., Arizona 
State Univ., Tempe, AZ 85287, phone (602) 
965-2855. 

ICSE 12,12th Int’l Conf. on Software 
Engineering, Mar. 26-30, Nice, France. 
Cosponsors: ACM, AFCET. Contact Francois- 
Regis Valette, CERT/DERI, PO Box 4026-2, 
Ave. Edouard Belin-31055 Toulouse, France, 
phone (33) 61-55-71-11; ICSE 12, AFCET, 

156 Bd. Pereire, 75017 Paris, France; or IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

^2^ 1990 Int’l Conf. on Extending Data- 
base Technology, Mar. 26-30, Venice, 
Italy. Cosponsors: EDBT Foundation et al. 
Contact Michael L. Brodie, Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan 
Rd„ MS 62, Waltham, MA 02254, phone (617) 
466-2256. 


CHI 90, Human Factors in Computing Sys¬ 
tems 1990, Apr. 1-5, Seattle. Sponsor: ACM. 
Contact Assoc, for Computing Machinery, 11 
W. 42nd St., New York, NY 10036. 

Fourth Parallel Processing and Neu- 
Kjp' ral Network Symp., Apr. 3-5, Fuller¬ 
ton, Calif. Cosponsor: California State Univ. at 
Fullerton. Contact Larry H. Canter, c/o Com¬ 
puter Systems Approach, 1140 S. Raymond 
Ave., Suite B., Fullerton, CA 92631, phone 
(714) 738-3414 

Disco 90, Int’l Symp. on Design and Imple¬ 
mentation of Symbolic Computation Sys¬ 
tems, Apr. 10-12, Gapri, Italy. Contact Alfonso 
Miola, Dip. Informatica e Sistemistica, Via 
Buonarroti, 12, 00185 Roma, Italy, phone 39 
(6) 731-2367. 

,£2N First Int’l Conf. on Systems Integra- 
tion, Apr. 23-26, Morristown, N.J. 
Sponsor: New Jersey Inst, of Technology. Con¬ 
tact Peter A. Ng, Computer and Information 
Science Dept., New Jersey Inst, of Technology, 
Newark, NJ 07102, phone (201) 596-3387. 

COIS 90, Conf. on Office Information 
Systems, Apr. 25-27, Cambridge, Mass. 
Sponsor: ACM. Contact Robert B. Allen, Rm. 
2A-367, Bellcore, 444 South St., Morristown, 
NJ 07960-1910, phone (201) 829-4280 or 4315. 


May 1990 


10th IEEE Symp. on Mass Storage Sys- 
'54^ terns, May 6-10, Monterey, Calif. Con¬ 
tact Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 

^2N CompEuro 90, IEEE Int’l Conf. on 
Computer Systems and Software En¬ 
gineering, May 7-9, Tel Aviv. Cosponsors: 
IEEE Region 8, IEEE Israel Section, IEEE 
Computer Society Israel Chapter. Contact 
CompEuro 90 Conf. Secretariat, c/o ORTRA, 2 
Kaufman St., PO Box 50432, Tel Aviv, 61500, 
Israel, phone 972 (3) 664-825. 

1990 IEEE Symp. on Research in Secu- 
rity and Privacy, May 7-9, Oakland, 
Calif. Contact Deborah Cooper, Aerospace 
Corp., MS: M8/055, 2350 E. El Segundo Blvd., 
El Segundo, CA 90245-4691, phone (213) 
336-3052. 

First Conf. on Visualization in Bio- 
medical Computing, May 22-25, At¬ 
lanta. Cosponsors: Nat’l Science Foundation 
et al. Contact Norberto Ezguerra, Bioengineer¬ 
ing Center, Georgia Tech, Atlanta, GA 30332, 
phone (404) 894-7026 or 3964. 

SIGMetrics 90, May 22-25, Boulder, Colo. 
Sponsor: ACM. Contact Gary J. Nutt, Univ. of 
Colorado, Boulder, CO 80301; or Herb 
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,£}N, 20th Int’l Symp. on Multiple-Valued 
*51? Logic, May 23-25, Charlotte, N.C. Con¬ 
tact George Epstein, Computer Science Dept., 
Univ. of North Carolina at Charlotte, 214 Ken¬ 
nedy Bldg., Charlotte, NC 28223, phone (704) 
547-4566; or Carolyn F. Blalock, Office of 
Continuing Education, Univ. of North Caro¬ 
lina at Charlotte, Charlotte, NC 28223, phone 
(704) 547-4861. 

1990 American Control Conf., May 23-25, 

San Diego, Calif. Sponsor: American Auto¬ 
matic Control Council. Contact Dagfinn 
Gangsaas, Boeing Advanced Systems, PO Box 
3707, MS 33-12, Seattle, WA 98124-2207, 
phone (206) 241-4348. 

17th Int’l Symp. on Computer Archi- 
*5*7 tecture, May 28-31, Seattle. Cosponsor: 
ACM. Contact Jean L. Baer or Larry Snyder, 
Univ. of Washington, Computer Science 
Dept., FR-35, Seattle, WA 98195, phone (206) 
543-1695. 

ICDCS 10, 10th Int’l Conf. on Distrib- 
'50' Uted Computing Systems, May 28- 
June 1, Paris. Cosponsor: INRIA. Contact R. 
Popescu-Zeletin, GMD-FOKUS, Harden- 
bergplatz 2, D-1000 Berlin 12, West Germany, 
phone 49 (30) 25499-206; Jack Stankovic, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-0720; or ICDCS 10, IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

11th Conf. of the Canadian Applied Mathe¬ 
matics Society, May 29-June 1, Halifax, N.S., 
Canada. Cosponsors: CAMS et al. Contact 
Mary Meidell, Continuing Education Dept., 
Technical Univ. of Nova Scotia, PO Box 1000, 
Halifax, NS B3J 2X4, Canada, phone (902) 
429-8300, ext. 2420. 


June 1990 


ZSN IEEE Infocom 90, Ninth Conf. on 
*5j? Computer Communications, June 3-7, 

San Francisco. Cosponsor: IEEE Communica¬ 
tions Society. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

Ninth Int’l Conf. on Analysis and Optimi¬ 
zation of Systems, June 12-15, Antibes, 
France. Sponsor: INRLA. Contact Conf. Secre¬ 
tariat, INRIA, Service des Relations Exter- 
ieures, Domaine de Voluceau — BP 105, 

78153 Le Chesnay Cedex, France, phone 33 
(D-39-63-5500. 

10th Int’l Conf. on Pattern Recogni- 
*51? tion, June 17-21, Atlantic City, NJ. Con¬ 
tact Herbert Freeman, CAIP Center, 605 Hill, 


Rutgers Univ., New Brunswick, NJ 08903, 
phone (201) 932-4208. 

Seventh Int’l Conf. on Testing Computer 
Software, June 18-21, San Francisco. Contact 
Genevieve Houston-Ludlam, ISTC 90, c/o 
Frontier Technologies, 190 Admiral Cochran 
Dr., Suite 180, Annapolis, MD 21401, phone 
(301) 266-8244. 

Second Int’l Conf. on Software Engineering 
and Knowledge Engineering, June 21-23, 

Skokie, Ill. Sponsors: Knowledge Systems 
Inst., Univ. of Pittsburgh, and Inst, for Infor¬ 
mation Industries, Taiwan. Contact Shi-Kuo 
Chang, Computer Science Dept., Univ. of 
Pittsburgh, 322 Alumni Hall, Pittsburgh, PA 
15260, phone (412) 624-8490. 

NECC 90, 11th Nat’l Educational Comput¬ 
ing Conf., June 25-27, Nashville, Term. Spon¬ 
sor: Int’l Council for Computers in Education. 
Contact John D. McGregor, Computer Studies 
Dept., Murray State Univ., Murray, KY 42071, 
phone (502) 762-2614. 

Z2N DAC 90, 27th ACM/IEEE Design 
*55? Automation Conf., June 25-29, 

Orlando, Fla. Cosponsor: ACM. Contact Pat 
Pistilli, MP Associates, 7490 Clubhouse Rd., 
Suite 102, Boulder, CO 80301, phone (303) 
530-4333. 

FTCS 20, 20th Int’l Symp. on Fault- 
*5*7 Tolerant Computing, June 26-28, 

Newcastle upon Tyne, England. Cosponsors: 
Centre for Software Reliability, British Com¬ 
puter Society, IEE. Contact Neil Speirs, Com¬ 
puting Lab, Univ. of Newcastle upon Tyne, 
Newcastle upon Tyne, NE1 7RU, UK, phone 
44 (91) 232-8511. 


August 1990 


July 1990 


UPADI 90, 21th Convention of the Pan 
American Federation of Engineering Socie¬ 
ties, Aug. 19-24, Washington, DC. Cospon¬ 
sors: American Assoc, of Engineering Socie¬ 
ties, American Society of Civil Engineers. 
Contact UPADI 90, ASCE, 345 E. 47th St., 
New York, NY 10017, phone (212) 705-7218. 

Coling 90, 13th Int’l Conf. on Computa¬ 
tional Linguistics, Aug. 20-25, Helsinki, Fin¬ 
land. Contact Hans Karlgren, KVAL, 
Skeppsbron 26, S-lll 30 Stockholm, Sweden, 
phone 46 (8) 789-6683. 


October 1990 


Infojapan 90, Int’l Conf. on Informa- 
'5*7 tion Technology, Oct. 1-5, Tokyo. 
Sponsor: IPSJ. Contact Haruhisa Ishida, Com¬ 
puter Center, Univ. of Tokyo, 2-11-16 Yayoi, 
Bunkyo-ku, Tokyo 113, Japan, phone 81 (3) 
818-0287. 

Frontiers 90, Oct. 8-10. Cosponsor: 
*5*7 NASA. Contact Johanna Weinstein, 
UMIACS, Univ. of Maryland, A.V. Williams 
Bldg., College Park, MD 20742, phone (301) 
454-1808. 

Compsac 90, 14th Int’l Computer 
*5§? Software and Applications Conf., Oct. 
31-Nov. 2, Chicago. Contact Stephen S. Yau, 
CIS Dept., 801 CSE, Univ. of Florida, Gaines¬ 
ville, FL 32611, phone (904) 335-8006. 


,£2^1 Second Int’l Symp. on Databases in 
*51? Parallel and Distributed Systems, July 
2-4, Dublin, Ireland. Cosponsor: ACM. Con¬ 
tact Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David Bell, 
Inst, of Informatics, Univ. of Ulster, Jordans- 
town, County Antrim, Northern Ireland 
BT370QB, phone (0232) 365-131. 

ICALP 90,17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming, July 
16-20, Coventry, England. Sponsor: Int’l 
Computers, Ltd. Contact Computer Science 
Dept., Univ. of Warwick, Coventry CV4 7AL, 
UK, phone 44 (203) 523-194. 

DIAC 90, Directions and Implications of 
Advanced Computing, July 28, Boston. 
Sponsor: Computer Professionals for Social 
Responsibility. Contact Douglas Schuler, 
Boeing Computer Services, MS 7L-64, PO 
24346, Seattle, WA 98124-0346, phone (206) 
865-3226. 


November 1990 


ICCC 90, 10th Int’l Conf. on Computer 
Communication, Nov. 5-9, New Delhi, India. 
Sponsor: Int’l Council on Computer Commu¬ 
nication. Contact P.P. Gupta, CMC Ltd., 1 
Ring Rd., Kilokri, New Delhi-110 014, India. 

ICCAD 90, IEEE Int’l Conf. on Com- 
*5*7 puter-Aided Design, Nov. 12-15. Co¬ 
sponsor: IEEE Circuits and Systems Society. 
Contact ICCAD 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

Supercomputing 90, Nov. 12-16, New 

*5*? York City. Cosponsor: ACM. Contact 
Supercomputing 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

13th Western Educational Computing 
Conf. Nov. 15-16, Irvine, Calif. Sponsor: Cali¬ 
fornia Educational Computing Consortium. 
Contact Oliver Seely, Jr., California State 
Univ. at Dominguez Hills, Chemistry, 1000 E. 
Victoria St., Carson, CA 90747. 

Cognitiva 90, Nov. 20-23, Madrid. 

*5*7 Sponsor: AFCET. Contact Cognitiva 90, 
c/o AFCET, 156 Bd Pereire 75017 Paris, 
France, phone 33 (01) 47-66-24-19. 
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CALL FOR PAPERS 


IEEE Trans. Parallel and Distributed 
Computing will begin quarterly publica¬ 
tion in January 1990. Sample subject areas in¬ 
clude parallel and distributed architectures, 
parallel and distributed software, and parallel 
algorithms and applications. Submit paper to 
Tse-yun Feng, Editor-in-Chief, IEEE TPDC, 
Computer Engineering Program, Electrical 
Engineering Dept., Pennsylvania State Univ., 
University Park, PA 16802. 


£2^. IEEE Micro seeks articles for general¬ 
's*? interest issues in 1990. Suggested topics 
include neural networks, artificial intelli¬ 
gence, special-purpose computers, optical 
computers and interfaces, workstations, use of 
microprocessors in parallel computers, VHDL 
design, silicon compilation, and biological 
computing. Tutorials are welcome on all micro- 
related topics. Submit manuscripts to Joe 
Hootman, Editor-in-Chief, EE Dept., Univ. of 
North Dakota, PO Box 7165, Grand Forks, ND 
58202, phone (701) 777-4331. 

First Int’l Symp. on Artificial Intelligence 
and Mathematics: Jan. 3-5, 1990, Fort Lau¬ 
derdale, Fla. Submit paper to Frederick 
Hoffman, Mathematics Dept., Florida Atlantic 
Univ., PO Box 3091, Boca Raton, FL 33431 - 
0991, phone (407) 367-3340. 


IEEE Computer Society 1990 Int'l 
Conf. on Computer Languages, Mar. 
12-16, New Orleans. Submit paper by Sept. 22, 
1989, to Alexander L. Wolf, AT&T Bell Labo¬ 
ratories, MH 3C-533, 600 Mountain Ave., 
Murray Hill, NJ 07974, phone (201) 582-6443. 

CAIA 90, Sixth IEEE Conf. on Artifi- 
's|? cial Intelligence Applications: Mar. 5- 
9, 1990, Santa Barbara, Calif. Submit paper by 
Sept. 29,1989, to Se June Hong, IBM T.J. Wat¬ 
son Research Center, Rm. 31-206, PO Box 218, 
Yorktown Heights, NY 10598, phone (914) 
945-2265. 


Ninth Int’l Conf. on Analysis and Optimiza¬ 
tion of Systems: June 12-15, 1990, Antibes, 
France. Sponsor: INRIA. Submit paper by Oct. 
1, 1989, to Conference Secretariat, INRIA, 
Service des Relations Exterieures, Domaine de 
Voluceau—BP 105, 78153 Le Chesnay Cedex, 
France, phone 33 (l)-39-63-5500. 

Disco 90, Int’l Symp. on Design and Imple¬ 
mentation of Symbolic Computation Sys¬ 
tems: Apr. 10-12, 1990, Capri, Italy. Submit 
abstract and paper by Oct. 10,1989, to Alfonso 
Miola, Dip. Informatica e Sistemistica, Via 
Buonarroti, 12, 00185 Roma, Italy, phone 39 
(6) 731-2367. 


10th Int’l Conf. on Pattern Recogni- 
tion: June 17-21, 1990, Atlantic City, 
NJ. Submit paper by Sept. 30,1989, to John 
Jarvis, Rm. 48601, AT&T Bell Labs, Holmdel, 
NJ 07733, phone (201) 949-2392. 


11th Conf. of the Canadian Applied Mathe¬ 
matics Society: May 29-June 1, 1990, Halifax, 
N.S., Canada. Cosponsors: CAMS et al. State 
intent to submit abstract by Sept. 30, 1989, and 
submit abstract by Nov. 20, 1989, to Matlur 
Rahman, Applied Mathmetics Dept., Technical 
Univ. of Nova Scotia, PO Box 1000, Halifax, 
NS B3J 2X4, Canada, phone (902) 420-7724. 


FTCS 20, 20th Int’l Symp. on Fault¬ 
'S*? Tolerant Computing, June 26-28, 
1990, Newcastle upon Tyne, England. Co¬ 
sponsors: Centre for Software Reliability, 
British Computer Society, IEE. Submit ab¬ 
stract by Oct. 13, 1989, to Bev Littlewood, 
CSR, City Univ., Northampton Square, Lon¬ 
don EC IV 0HB. 


NECC 90,11th Nat’l Educational Computing 
Conf.: June 25-27, 1990, Nashville, Tenn. 
Sponsor: Int’l Council for Computers in Edu¬ 
cation. Submit paper by Oct. 15, 1989, to John 
D. McGregor, Computer Studies Dept., Mur- 


Call for papers and referees for 
Computer 


\ Computer seeks articles for inclusion in upcoming 
7 special issues. 


Cache and Interconnect Architectures in Multipro¬ 
cessors has been selected as the theme for the June 1990 
edition. Manuscripts are sought immediately in the following 
areas: 

• New solutions to the cache coherence problem: novel hard¬ 
ware protocols and compiler-assisted cache protocols; em¬ 
phasis is on protocols for nonbus systems. 

• Detailed descriptions of existing commercial systems and 
university or industry prototypes. 

• Caching support for virtual memory and virtual-address 
caches in multiprocessors. 

• Trace-driven simulation techniques and results for cache- 
based multiprocessors. 

• Other performance-evaluation techniques, such as mea¬ 
surements, execution-driven simulation, and analytical models. 

In addition, a tutorial paper on cache coherence and virtual 
memory for multiprocessor systems is solicited. This tutorial 
should contain background material needed by a computer 
scientist unfamiliar with the theme of this special issue. 


Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract should be submitted by e-mail or fax as 
soon as possible. Eight copies of the full manuscript must be 
submitted by November 1, 1989, to Michel Dubois, Depart¬ 


ment of EE-Systems, Univ. of Southern California, Los Ange¬ 
les, CA 90089-0781, phone (213) 743-8080, fax (213) 745- 
7284, electronic-mail dubois@cse.usc.edu; or Shreekant 
Thakkar, Sequent Computer Systems, 15450 SW Koll Park¬ 
way, Beaverton, OR 97006, phone (503) 627-9822, fax (503) 
526-5797, electronic-mail sequentlticky@decwrl.dec.com 

Authors will be notified of acceptance by January 1,1990. 
The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Bruce Shriver, Editor-in-Chief, Computer , c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmail+ 
b.shriver, Internet shriver@usl.edu 

Fault-Tolerant Systems has been selected as the theme 
for the July 1990 edition. Submittals should be either tutorial 
or survey in nature, describe state-of-the-art designs, or re¬ 
port recent developments and research findings in the follow¬ 
ing areas: fault-tolerant hardware, fault-tolerant software, 
fault-tolerant distributed systems and networks, modeling and 
evaluation, fault-tolerant commercial systems, special-pur¬ 
pose designs, and emerging areas. 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract of the manuscript is due as soon as pos¬ 
sible, and eight copies of the full manuscript must be submitted 
by November 1,1989, to Adit D. Singh, Electrical and Com¬ 
puter Engineering, University of Massachusetts, Amherst, MA 
01003, phone (413) 545-0188, electronic-mail: 
singh@umaecs.edu; or Singaravel Murugesan, Information 
Sciences Division, NASA Ames Research Center, MS 244-4, 
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Second Int’l Symp. on Databases in 
^■7 Parallel and Distributed Systems: July 
2-4, 1990, Dublin, Ireland. Cosponsor: ACM. 
Submit paper by Oct. 16,1989, to Rakesh 
Agrawal, AT&T Bell Labs, Rm. 3D450, 600 
Mountain Ave., Murray Hill, NJ 07974, phone 
(201) 582-2250; or David Bell, Inst, of Infor¬ 
matics, Univ. of Ulster, Jordanstown, County 
Antrim, Northern Ireland BT370QB, phone 
(0232) 365-131. 

^ ICDCS 10, 10th Int’l Conf. on Distrib- 
^§7 uted Computing Systems: May 28-June 
1, 1990, Paris. Cosponsor: INRIA. Submit ab¬ 
stract and paper by Oct. 20,1989, to Jack 
Stankovic, Computer and Information Science 
Dept., Univ. of Massachusetts, Amherst, MA 
01003, phone (413) 545-0720; or R. Popescu- 
Zeletin, GMD-FOCUS, Hardenbergplatz 2, 
D-1000 Berlin 12, West Germany, phone 49 
(30) 25499-206. 

£5^ 20th Int’l Symp. on Multiple-Valued 

Logic: May 23-25, 1990, Charlotte, N.C. 
Cosponsors: Microelectronic Center of North 
Carolina, Univ. of North Carolina. Submit pa¬ 
per by Nov. 1,1989, to George Epstein, Com¬ 
puter Science Dept., Univ. of North Carolina at 
Charlotte, Charlotte, NC 28223, phone (704) 
547-4566. 

IEEE Trans, on Computers plans a spe- 

cial issue on computer arithmetic in Au¬ 
gust 1990. Submit paper by Nov. 1,1989, to 
Earl Swartzlander, TRW Defense Systems 


Group, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 812-0791. 

J. Parallel and Distributed Computing plans a 
special issue on software tools for parallel pro¬ 
gramming and visualization in June 1990. Sub¬ 
mit paper by Nov. 1,1989, to Lionel Ni, Com¬ 
puter Science Dept., Michigan State Univ., 

East Lansing, MI 48824-1027, phone (517) 
353-4386; or K.C. Tai, Computer Science 
Dept., North Carolina State Univ., Raleigh, NC 
27695-8206, phone (919) 737-7862. 

Seventh Int’l Conf. on Testing Computer 
Software: June 18-21, 1990, San Francisco. 
Submit abstract by Nov. 1, 1989, to Genevieve 
Houston-Ludlam, ISTC 90, c/o Frontier Tech¬ 
nologies, 190 Admiral Cochran Dr., Suite 180, 
Annapolis, MD 21401, phone (301) 266-8244. 


1^3^ COIS 90, Conf. on Office Information 

^7 Systems: Apr. 25-27, 1990, Cambridge, 
Mass. Sponsor: ACM. Submit paper by Nov. 3, 
1989, to Fred Lochovsky, Computer Science 
Dept., 10 King’s College Circle, Univ. of 
Toronto, Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-7441. 


1990 IEEE Symp. on Research in Secu- 
'^§7 rity and Privacy: May 7-9, 1990, 
Oakland, Calif. Submit paper by Nov. 6, 1989, 
to Deborah Cooper, Aerospace Corp., MS: M8/ 
055, 2350 E. El Segundo Blvd., El Segundo, 

CA 90245-4691, phone (213) 336-3052. 


17th Int’l Symp. on Computer Archi- 
'5*7 tecture: May 28-31, 1990, Seattle. Co¬ 
sponsor: ACM. Submit paper by Nov. 21, 


1989, to James Goodman, Computer Sciences 
Dept., Univ. of Wisconsin, 1210 W. Dayton, 
Madison, WI 53706, phone (608) 262-1204. 

Coling 90,13th Int’l Conf. on Computa¬ 
tional Linguistics: Aug. 20-25, 1990, Helsinki, 
Finland. Submit paper by Dec. 1,1989, to Hans 
Karlgren, KVAL, Skeppsbron 26, S-lll 30 
Stockholm, Sweden, phone 46 (8) 789-6683. 


IEEE Software plans a special Software 
n 57 Tools Fair issue in May 1990. Request 
special form from Paul Oman, Computer Sci¬ 
ence Dept., Engineering College, Univ. of 
Idaho, Moscow, ID 83843, phone (208) 885- 
6589. The submittal deadline is Dec. 15, 1989. 


Fourth Parallel Processing and Neu- 
^§7 ral Network Symp.: Apr. 3-5, 1990, 
Fullerton, Calif. Cosponsor: California State 
Univ. at Fullerton. Submit paper by Dec. 15, 
1989, to Larry H. Canter, c/o Computer Sys¬ 
tems Approach, 1140 S. Raymond Ave., Suite 
B„ Fullerton, CA 92631, phone (714) 738-3414 

Cognitiva 90: Nov. 20-23, 1990, 

'5i7 Madrid. Sponsor: AFCET. Submit ab¬ 
stract by Jan. 15,1990, to Cognitiva 90, c/o 
AFCET, 156 Bd Pereire 75017 Paris, France, 
phone 33 (01) 47-66-24-19. 


Infojapan 90, Int’l Conf. on Informa- 
tion Technology: Oct. 1-5, 1990, To¬ 
kyo. Sponsor: IPSJ. Submit paper by Feb. 1, 
1990, to Haruhisa Ishida, Computer Center, 
Univ. of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, 
Tokyo 113, Japan, phone 81 (3) 818-0287. 


Moffett Field, CA 94035, phone (415) 694-4233, ARPAnet: 
murugesan@pluto.arc.nasa.gov 

Authors will be notified of acceptance by February 1, 1990. 
The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Bruce Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmaik 
b.shriver, Internet shriver@usl.edu 

Voice In Computing has been selected as the theme for the 
August 1990 edition. Surveys, tutorials, system or application 
descriptions, or case-studies are solicited in the following ar¬ 
eas: computer interface to voice communications, voice ma¬ 
nipulation by computer, computer voice applications, inte¬ 
grated voice/data applications, voice in computer user inter¬ 
faces, speech synthesis or recognition systems, and com¬ 
puter architectures for supporting voice. 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract of the manuscript is due as soon as pos¬ 
sible, and eight copies of the full manuscript must be submitted 
by November 1, 1989, to Ragui Kamel, Computing Research 
Laboratory, Bell-Northern Research, PO Box 3511 — Station 
C, Ottawa, Canada K1Y 4H7, phone (613) 763-3609, fax (613) 
763-4222, electronic mail Ragui@BNR.CA 

Authors will be notified of acceptance by January 1, 1990. 
The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 


Bruce Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmaik 
b.shriver, Internet shriver@usl.edu 

Formal Methods for Software Engineering has been se¬ 
lected as the theme for coordinated special issues of 
Computer, IEEE Software, and IEEE Transactions on Soft¬ 
ware Engineering in September 1990. 

Formal methods are design and construction methods ex¬ 
plicitly based on well-defined mathematical formalisms. Ex¬ 
amples include VDM, Z, box structures, traces, predicate 
transformers, state transition systems, axiomatic data types, 
and many more. 

For the coordinated set of articles planned in September 
1990, multiple submissions of different types (for example, a 
case study with accompanying research description) are per¬ 
mitted. Computer will publish a survey plus tutorial, IEEE Soft¬ 
ware will carry application case studies, and IEEE Transac¬ 
tions on Software Engineering will publish research papers. 

Submit application case studies, tutorials, and surveys to 
Susan Gerhart, MCC Software Technology Program, 3500 W. 
Balcones Dr., Austin, TX 78759, phone (512) 338-3492, fax 
(512) 338-3899, electronic-mail gerhart@mcc.com 

Submit research contributions to Nancy Leveson, Informa¬ 
tion and Computer Science Dept., University of California, Irv¬ 
ine, CA 92717, phone (714) 856-5517, fax (714) 856-4056, 
electronic-mail nancy@ics.uci.edu 

Drafts must be submitted no later than October 1,1989. Re¬ 
views will be completed by March 1,1990, and revisions must 
be completed by May 1, 1990. 

Reviewers are sought who are willing to adhere to a tight 
timetable for publication of these special issues. 
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STUDENT MEMBERSHIP APPLICATION 


Students, Membership Is Part Of Being A 
Professional... Join The Computer Society Now! 


As a student member of the 
Computer Society, you will have a 
wealth of resources for professional 
success, both in school and beyond. 
The student cost to join is much less 
than you’d think—and the benefits, 
much greater. Among the many 
automatic benefits offered to IEEE/ 
Computer Society students are, 

□ Computer magazine monthly 

□ IEEE Spectrum, The Institute, 
and Potentials 

□ Local chapter activities 

□ Discounts on optional periodicals, 
Computer Society Press books, 
and conferences. 





AGREEMENT 


A IEEE COMPUTER SOCIETY 


9/89 CMP 


I hereby apply for IEEE Computer Society student membership and, if elected, 
will abide by the IEEE constitution and bylaws, and its statements of policies 
and procedures. 



THE INSTITUTE OF ELECTRICAL 
AND ELECTRONICS ENGINEERS, INC. 


Nonstudents interested in membership: 

Date see regular application elsewhere in this issue. 


Student’s signature 










































Implementing Software Engineering Practices 

Fletcher J. Buckley (John Wiley & Sons, New York, 1989, 172 pp„ $34.95) 


Most software development shops 
have adopted development standards, 
generally consisting of a commercial 
project-management methodology such 
as SDM 70 and Method 1.1 have observed 
that software developers find these stan¬ 
dards cumbersome, since they generate 
overhead that reduces productivity and 
restricts creativity. In practice, adher¬ 
ence to these standards means that the 
software developers are using the docu¬ 
mentation formats and meeting the pro¬ 
cedural milestones of these methodol¬ 
ogies, regardless of their appropriateness 
to the task at hand. 

Implementing Software Engineering 
Practices succinctly examines the pro¬ 
cesses and products for engineering and 
managing large software projects. The 
author provides guidelines for develop¬ 
ing standards and practices that adapt 
well to an organization’s culture and are 
tailored to the unique needs of the indi¬ 
viduals in that organization. The book’s 
short chapters collectively reveal a spec¬ 
trum of software engineering practices as 
they apply to the various phases of soft¬ 
ware development. 

The author uses a stepwise refinement 


approach to introduce and explain his 
methodology for evolving a standardized 
development process. In Chapter 2, he 
provides an overview of establishing pol¬ 
icy and implementation guidelines. 

In Chapter 3, the author outlines the 
documents that serve as a development 
framework. He introduces such notions 
as grandfather clauses, escape clauses, 
and termination clauses, and he presents 
a skeletal format for writing a policy 
document in terms of what needs to be 
done, who will do it, and who is respon¬ 
sible. The author uses this skeletal format 
throughout the text to formulate sample 
policy statements that can be adapted by 
practitioners to develop their own poli¬ 
cies and standards. 

The rest of the book provides specific 
details for the different phases of the de¬ 
velopment life cycle. Each chapter focuses 
on developing policies and generating pro¬ 
cedures that put the policies into practice. 

In Chapter 4, the author discusses how 
to execute the requirement definition 
phase and identifies seven products of the 
phase: software requirement specifica¬ 
tions, external interface specifications, 
acceptance test plans, development 


plans, configuration management plans, 
quality assurance plans, and the stan¬ 
dards and procedures manual. He then 
devotes a chapter to each product to de¬ 
scribe the policies, how to establish them, 
and the tradeoffs involved. 

The author discusses the software de¬ 
sign phase in Chapter 13 and identifies 
five sets of documents: top-level design 
description, integration plan, test proce¬ 
dures, user documentation, and changes 
to all previously approved documents. 

He also discusses the issues involved in 
establishing policies for these documents. 

The appendix contains a comprehen¬ 
sive bibliography of IEEE and DoD stan¬ 
dards and illustrations of requirement 
specifications and design specifications. 

Although software engineering practi¬ 
tioners are the primary audience for this 
book, it is an excellent text to support a 
projects course in software development 
or computer information systems. It 
should be required reading for graduate 
students in software engineering and ap¬ 
plied computing programs. 

Donald R. Chand 

Bentley College 


NEW LITERATURE 


Security advice. In Computer and 
Communications Security: Strategies for 
the 1990s (ISBN 0-07-012926-6, 411 
pp., $44.95), author James Arlin Cooper • 
presents information on security tech¬ 
niques that will be available in the next 
decade and surveys safeguards against 
security threats. The author examines 
problems in six principal areas: physical, 
personnel, regulatory, hardware, soft¬ 
ware, and network security. He discusses 
software viruses and malfunctions, natu¬ 
ral disasters, and technological advances 
that can be used to exploit security weak¬ 
nesses. He also explains hardware de¬ 
vices, software strategies, mathematical 
approaches, and protective techniques. A 
number of case studies illustrate the issues. 

Contact McGraw-Hill, 11 W. 19th St., 
New York, NY 10011, phone (800) 262- 
4729. 

Fractals. Fractal Programming in C 
(book only, ISBN 1-55851-037-0, 600 
pp., $24.95; book and disk, ISBN 1- 


55851-038-9, 600 pp., $39.95) by Roger 
T. Stevens explores such fractals as the 
von Koch snowflake, the Gosper curve, 
dragon curves, and the Mandelbrot set, as 
well as the software for plotting and in¬ 
vestigating them. The book includes over 
100 black-and-white and 32 full-color 
fractal illustrations. The author also de¬ 
scribes how to create displays of the Julia 
set and offers C language programs to re¬ 
produce all the fractals in the book. The 
available MS-DOS format disk contains 
the source code to reproduce over 100 
fractals. The programs require an IBM 
PC or compatible with EGA or VGA card, 
color monitor, and a Turbo C, Quick C, or 
Microsoft C compiler. 

Contact M&T Books, 501 Galveston 
Drive, Redwood City, CA 94063, phone 
(415) 336-3600. 

CS Press offerings. The IEEE Com¬ 
puter Society Press has recently pub¬ 
lished the following books: 

Analyzing Computer Architectures 


(ISBN 0-8136-8857-2, Order No. 857, 
200 pp., $31.50 members, $42 nonmem¬ 
bers) by Jerome C. Huck and Michael J. 
Flynn studies and compares architec¬ 
tures by measuring the execution of two 
identical sets of high-level-language pro¬ 
grams. The analysis relies on observable 
measures that reflect the effectiveness of 
an instruction set. Other measures include 
storage requirements and execution times. 

Modeling and Control of Automated 
Manufacturing Systems (ISBN 0-8186- 
8916-1, Order No. 1916, 450 pp„ $55 
members, $41 nonmembers) by Alan A. 
Desrochers surveys and summarizes cur¬ 
rent research related to systems issues in 
automation and flexible manufacturing. 
The control methods presented are 
emerging mathematical techniques with 
purported potential for changing the way 
manufacturing systems operate. 

Contact IEEE Computer Society Press, 
Order Dept., 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720, phone (800) 
272-6657 (in California, (714) 821-8380). 
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Membership / Subscription Application 


BENEFITS 



Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called “The Open Channel." 
(monthly). 


Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50% on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 


To join: see item 1, 2, or 3. 
Schedule of Fees To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, 
and expire on, December 31. Choose full or half-year rate schedules 
depending on date of receipt by the Computer Society Half Ysar Full Year 

as indicated below._Mar 1-Aug 31 Sept 1-Feb 28 


I don’t belong to the IEEE and I want 
to join just the Computer Society 


□ $19.50 □ $39.00 


) I don’t belong to the IEEE and I want 
■ to join both the Computer Society and the IEEE* 

(Total amount to be paid includes annual dues, and regional assessment, if any.) 


I reside in Region 1-6 (United States). 

I reside in Region 7 (Canada). 

I reside in Region 8 (Eu rope, Africa, or the M iddle East) 

I reside in Region 9 (Latin America). 

I reside in Region 10 (Asia and Pacific) 


□ $44.00 □$88.00 

□ $41.00 □$82.00 

□ $41.50 □$83.00 

□ $36.00 □ $72.00 

□ $37.00 □ $74.00 


id the Computer Society may deduct $5 off the 


( I already belong to the IEEE and I want 
to join the Computer Society. 

IEEE Member Number_ 


□ $ 7.50 □ $15.00 


^ OPTIONAL PERIODICALS for new or currerit members 

IEEE Computer Graphics and Applications (3061) 6 

IEEE Design and Test (3111) .6 

IEEE Expert (3151) .4 

IEEE Micro (3071) .6 

IEEE Software (3121) .6 

Transactions on Computers (1161) .12 

Transactions on Knowledge and 

sp'^ 9 Data Engineering (1471) .4 

Transactions on Pattern Analysis and 

Machine Intelligence (1351) .12 

Transactions on Software Engineering (1171) .12 

Total amount remitted with this application $ 

□ Checks are accepted in Belgian, British, German, Swiss, Japanese, or 
U.S. currencies. U.S. checks must be drawn on a U.S. bank. 

□ Visa □ Master Card □ American Express □ Eurocard □ Diners Club 

I I I I I I I I II I I I I I I I 

Charge Card Number 


□ 

$ 9.50 

□ 

$19.00 

□ 

$10.00 

□ 

$20.00 

□ 

$ 6.00 

□ 

$12.00 

□ 

$ 9.00 

□ 

$18.00 

□ 

$ 9.00 

□ 

$18.00 

□ 

$10.00 

□ 

$20.00 

□ 

$ 5.00 

□ 

$10.00 

□ 

$10.00 

□ 

$20.00 

□ 

$10.00 

□ 

$20.00 


1 hereby make application for Computer Society membership and, if elected, will b 
policies and procedures. 

MAILING ADDRESS 

e governed by IEEE’s and the society's constitutions, bylaws, and statements of 

Full signature 


State/Ccuntry Zip 


EDUCATION (highest level co 


REFERENCE (an IEEE me 


Return with your remittance to: IEEE Computer Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-2578 USA 

Residents of Europe mail to: IEEE Computer Society, 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM 

Asia/Pacific residents mail to: IEEE Computer Society, Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107 JAPAN 
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technical information among 100,000 members worldwide, and 
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tutorial and in-depth articles on topics across the computer field, 
plus news, conferences, calendar, interviews, and new products. 
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Conference Proceedings, Tutorial Texts, Standard 
Documents. The Computer Society Press publishes more than 
100 titles every year. 

Standards Working Groups. Over 100 of these groups produce 
IEEE standards used throughout the industrial world. 

Technical Committees. More than 30 TCs publish newsletters, 
provide interaction with peers in specialty areas, and directly 
influence standards, conferences, and education. 
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NEW FOR NETWORK ANALYSTS 



Realistic simulation of your network or embedded 
computer system, quick results-no programming 


NETWORK II.5 now predicts performance of 
computer-communication nets including LAN’s 

Free trial and, if you act now, free training 


N etwork 11.5 uses 

simulation to predict your 
network performance. You simply 
describe your network and work¬ 
load. 

Animated simulation follows im- 
mediately—no programming delays. 

Easy-to-understand results 

You get an animated picture of 
your network. System bottlenecks 
and changing levels of utilization 
are apparent. 

You can simulate some portions 
of the network at a detailed level 
and others at a coarser level. 

Your reports show response 
times, messages delivered, messages 
lost, device utilization, and queue¬ 
ing statistics. 

Computers with NETWORK II.5 

NETWORK II.5 is available for 
most PC’s, Workstations, and 
Mainframes. 


Your network simulated 

You can analyze any LAN, 
embedded computer system, or 
other computer-communication net¬ 
work. Industry standard protocols 
such as FDDI and IEEE Standard 
802.X are built-in. Others can be 
modeled. 

You can easily study the effect of 
changing network parameters or 
even network protocols. 

Seeing your network animated in¬ 
creases everyone’s understanding of 
its operation and builds confidence 
in your results. 

Free trial information 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. For a limited 
time we also include free training 
-no cost, no obligation. 

Call Paul Gorman at (619) 
457-9681, FAX (619) 457-1184. In 
Europe, call Richard Eve on (01) 
528-7980, FAX (01) 528-7988. 


I Free trial offer 

I See for yourself how NETWORK II.5 
I quickly answers network performance 
questions. 

I Limited offer-Act now for free training. 

| DSend information on your Special 
University Offer. 



CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Paul Gorman at (619) 457-9681. 
FAX (619) 457-1184. 

In Europe: 

CACI Products Division 

Regent House, 89 Kingsway 

London WC2B 6RH, United Kingdom 

Call Richard Eve on (01) 528-7980. 
FAX (01) 528-7988. 


NETWORK II.5 is a registered trademark and service 
mark of CACI, INC. 

©1989 CACI, INC. 
















